From mickgray@au1.ibm.com Sun Nov 1 12:50:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59C63A6767 for ; Sun, 1 Nov 2009 12:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, 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 oRgLfljDPvLs for ; Sun, 1 Nov 2009 12:50:22 -0800 (PST) Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by core3.amsl.com (Postfix) with ESMTP id 9B96C28C11A for ; Sun, 1 Nov 2009 12:50:09 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp09.au.ibm.com (8.14.3/8.13.1) with ESMTP id nA1KoRGf004936 for ; Mon, 2 Nov 2009 07:50:27 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nA1KlQQk1613972 for ; Mon, 2 Nov 2009 07:47:26 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nA1KoQnN003638 for ; Mon, 2 Nov 2009 07:50:26 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nA1KoQB5003635; Mon, 2 Nov 2009 07:50:26 +1100 In-Reply-To: <4AE9F0DE.7060903@pobox.com> To: "Michael D'Errico" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Mon, 2 Nov 2009 06:50:02 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 02/11/2009 07:56:56 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: tls@ietf.org Subject: Re: [TLS] Server Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 20:50:23 -0000 DQoiTWljaGFlbCBEJ0VycmljbyIgPG1pa2UtbGlzdEBwb2JveC5jb20+IHdyb3RlOg0KDQo+IFRo ZXJlIGFyZSBub3cgYXQgbGVhc3QgMyBpbnN0YW5jZXMgd2hlcmUgYSBUTFMgY2xpZW50IG5lZWRz IHRvIGtub3cgdGhlDQo+IHNlcnZlcidzIGxpc3Qgb2Ygc3VwcG9ydGVkIHNpZ25hdHVyZSBhbGdv cml0aG1zOg0KPg0KPiAgICAgMS4gdG8gY29tcHV0ZSB0aGUgc2lnbmF0dXJlIGZvciB0aGUgQ2Vy dGlmaWNhdGVWZXJpZnkgbWVzc2FnZQ0KPiAgICAgMi4gdG8gY29tcHV0ZSB0aGUgaGFzaCBvZiB0 aGUgaGFuZHNoYWtlIG1lc3NhZ2VzIGluICgxKSB3aXRob3V0DQo+ICAgICAgICBoYXZpbmcgdG8g aG9sZCBvbnRvIGFsbCBvZiB0aGUgbWVzc2FnZXMNCj4gICAgIDMuIHRvIGNvbXB1dGUgaGFzaGVz IGZvciB0aGUgcHJvcG9zZWQgY2FjaGVkIGluZm9ybWF0aW9uIGV4dGVuc2lvbg0KPg0KPiBSYXRo ZXIgdGhhbiBkdXBsaWNhdGUgdGhlIGxpc3QgZm9yIGVhY2ggb2YgdGhlc2UgYW5kIGFueSBmdXR1 cmUgbmVlZHMsDQo+IGl0IG1ha2VzIHNlbnNlIHRvIHNlbmQgaXQgb25jZSBpbiBhIHNlcnZlciBo ZWxsbyBleHRlbnNpb24uDQo+DQo+IFRoZSBzaW1wbGVzdCBvcHRpb24gd291bGQgYmUgdG8gdXNl IHRoZSBleGlzdGluZyBzaWduYXR1cmUgYWxnb3JpdGhtcw0KPiBleHRlbnNpb24gYW5kIG1ha2Ug aXQgc3ltbWV0cmljYWwuICBCdXQgaWYgdGhlcmUgaXMgYSBkZXBsb3llZCBjbGllbnQNCj4gb3V0 IHRoZXJlIHRoYXQgYWJvcnRzIGEgY29ubmVjdGlvbiBpZiBpdCByZWNlaXZlcyBhIHNpZ25hdHVy ZSBhbGdvcml0aG0NCj4gZXh0ZW5zaW9uLCB0aGVuIGEgc2Vjb25kYXJ5IG9wdGlvbiB3b3VsZCBi ZSB0byBjcmVhdGUgYSBuZXcgc2VydmVyLQ0KPiBzaWduYXR1cmUtYWxnb3JpdGhtcyBleHRlbnNp b24gd2hpY2ggaXMgaWRlbnRpY2FsIGluIHN0cnVjdHVyZSB0byB0aGUNCj4gZXhpc3RpbmcgZXh0 ZW5zaW9uLg0KPg0KPiBJIHdvdWxkIGFkZCB0aGF0IHdoZW4gdGhlIHNlcnZlciBzZW5kcyBpdHMg bGlzdCBvZiBhbGdvcml0aG1zIGluIHRoZQ0KPiBleHRlbnNpb24sIHRoZW4gaXQgTVVTVCBOT1Qg c2VuZCBhIGRpZmZlcmVudCBsaXN0IGluIHRoZSBjZXJ0aWZpY2F0ZQ0KPiByZXF1ZXN0IG1lc3Nh Z2U7IGluIGZhY3QgaXQgU0hPVUxEIHNlbmQgYW4gZW1wdHkgbGlzdC4gIFRMUyAxLjMgY2FuDQo+ IGRlY2lkZSB3aGV0aGVyIHRvIGVsaW1pbmF0ZSB0aGUgbGlzdCBmcm9tIENlcnRpZmljYXRlUmVx dWVzdC4NCg0KQ3VycmVudGx5IG91ciB0b29sa2l0IHdoZW4gb3BlcmF0aW5nIGFzIGEgY2xpZW50 IHdpbGwgYWJvcnQgdGhlIGhhbmRzaGFrZQ0Kb24gdGhpcyBjb25kaXRpb24gZHVlIHRvIFJGQyA1 MjQ2IGluIDcuNC4xLjQuMSBzYXlpbmc6IOKAnFNlcnZlcnMgTVVTVCBOT1QNCnNlbmQgdGhpcyBl eHRlbnNpb27igJ0uDQoNCldlIGNvdWxkIGNoYW5nZSBvdXIgY29kZSB0byBvcHRpb25hbGx5IChl LmcuIGEgbm9uIHN0cmljdCBtb2RlKSBhY2NlcHQNCnJlY2VpdmluZyB0aGUgZXh0ZW5zaW9uIGZy b20gYSBUTFMgU2VydmVyIGFzIHRoYXQgd291bGQgYmUgSU1ITyByZWxhdGl2ZWx5DQpoYXJtbGVz cy4gIFRoZSBwcm9ibGVtIEkgc2VlIHdvdWxkIGJlIGlmIHdlIGVuYWJsZWQgb3VyIFNlcnZlciBz aWRlIGNvZGUgdG8NCm9wdGlvbmFsbHkgc2VuZCB0aGlzIGV4dGVuc2lvbiwgdGhhdCB3b3VsZCBv cGVuIHRoZSBkb29yIGZvciBleGlzdGluZyBUTFMNCkNsaWVudHMgdG8gYWJvcnQgdGhlIGhhbmRz aGFrZS4gIFdlIGhhdmUgbm8gaWRlYSB3aGljaCBDbGllbnQgKHZlbmRvcikgdHlwZQ0KbWF5IGJl IGludm9sdmVkIGluIGEgaGFuZHNoYWtlIGFuZCB3aGF0IHJldmlzaW9uIG9mIHRoZSBpbXBsZW1l bnRhdGlvbiBpbg0KdGhpcyBhcmVhIHRoZXkgbWlnaHQgc3VwcG9ydCBpLmUuLCB0aGVyZSBpcyBu byB3YXkgZm9yIHRoZSBDbGllbnQgdG8NCmluZGljYXRlIHRoYXQgaXQgd2lsbCB0b2xlcmF0ZSB0 aGUgU2VydmVyIHNlbmRpbmcgdGhlIGV4dGVuc2lvbi4gIElNSE8gSXQNCmlzIHVuZm9ydHVuYXRl IHZlcnNpb24gaW5mb3JtYXRpb24gaXMgbm90IGluY2x1ZGVkIGluIGVhY2ggZXh0ZW5zaW9uLiAg U28NCndoaWxlIEkgYWdyZWUgdGhhdCB0aGlzIHNvdW5kcyBhIGdvb2QgbW92ZSBJIHdvdWxkIGJl IGNvbmNlcm5lZCBhcyB0byB0aGUNCmltcGFjdCBvbiBzeXN0ZW0gYXZhaWxhYmlsaXR5IHNob3Vs ZCBhbnkgU2VydmVyIG5vdyBiZSBjb25maWd1cmVkIHRvIHN0YXJ0DQpzZW5kaW5nIHRoaXMgZXh0 ZW5zaW9uLiAgSU1ITyBJIHRoaW5rIHRoZSBob3JzZSBtaWdodCBoYXZlIGFscmVhZHkgYm9sdGVk DQppbiB0aGlzIGNhc2UgOi0oDQoNCk1pY2sNCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4gVExTQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz From mike-list@pobox.com Sun Nov 1 13:32:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA813A6822 for ; Sun, 1 Nov 2009 13:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 6IGceaZ3zSt7 for ; Sun, 1 Nov 2009 13:32:10 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id AEA9F3A67D6 for ; Sun, 1 Nov 2009 13:32:08 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D96FA8EF06 for ; Sun, 1 Nov 2009 16:32:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=MotZn9LPl7mu VhQsxfY6BV8GHdk=; b=RbJKFdszYTEe0OaqMS9V5bUguWedVVz7vldasjvZTyG7 +Cp7UDBnG3ZHNX4GvnltRf15Nf1OJBuJvobmjtsfM8GCrAY6wNjBCfXIRVmRY0zL unk37ro6fxnHSfQkGcFv9LE1WLcSXXCF6fYMk0x8k2nbNJPW0ZYDs3+mxrqxgOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=KxYdLv R8yFo8X8oVXL4R6Kb8BNZENHntvmBYMqBqNUYJyft7Lv2OzTpQLjnimxlBlUZaj7 Fz3tzdhsXGwTbGJKux3nU0Rx4lMzrJkrukMtRUV0lBFZ9X3WwPntVXc+ZhyGBdvj 9SbBF6ojvAlyHN3fQC8rQQ98VLKWXUe+H3YTI= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D629A8EF05 for ; Sun, 1 Nov 2009 16:32:27 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 2CC378EF03 for ; Sun, 1 Nov 2009 16:32:26 -0500 (EST) Message-ID: <4AEDFED0.7060505@pobox.com> Date: Sun, 01 Nov 2009 13:34:08 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed X-Pobox-Relay-ID: 0D9A25B2-C72E-11DE-9556-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] Server Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 21:32:11 -0000 So instead of changing the existing signature_algorithms extension, nothing would break by creating a new server_signature_algorithms extension. Client support would be advertised by sending an empty extension to the server. The server would show support by replying with its list. In this case, the server can leave the signature algorithms list in CertificateRequest empty since it knows the client accepted its list in the server hello extension. The server MUST NOT send a different list in CertificateRequest, since the client may have used the information to start computing the hash for CertificateVerify and thrown away the previous handshake messages. Mike Michael Gray wrote: > "Michael D'Errico" wrote: >=20 >> There are now at least 3 instances where a TLS client needs to know th= e >> server's list of supported signature algorithms: >> >> 1. to compute the signature for the CertificateVerify message >> 2. to compute the hash of the handshake messages in (1) without >> having to hold onto all of the messages >> 3. to compute hashes for the proposed cached information extension >> >> Rather than duplicate the list for each of these and any future needs, >> it makes sense to send it once in a server hello extension. >> >> The simplest option would be to use the existing signature algorithms >> extension and make it symmetrical. But if there is a deployed client >> out there that aborts a connection if it receives a signature algorith= m >> extension, then a secondary option would be to create a new server- >> signature-algorithms extension which is identical in structure to the >> existing extension. >> >> I would add that when the server sends its list of algorithms in the >> extension, then it MUST NOT send a different list in the certificate >> request message; in fact it SHOULD send an empty list. TLS 1.3 can >> decide whether to eliminate the list from CertificateRequest. >=20 > Currently our toolkit when operating as a client will abort the handsha= ke > on this condition due to RFC 5246 in 7.4.1.4.1 saying: =E2=80=9CServers= MUST NOT > send this extension=E2=80=9D. >=20 > We could change our code to optionally (e.g. a non strict mode) accept > receiving the extension from a TLS Server as that would be IMHO relativ= ely > harmless. The problem I see would be if we enabled our Server side cod= e to > optionally send this extension, that would open the door for existing T= LS > Clients to abort the handshake. We have no idea which Client (vendor) = type > may be involved in a handshake and what revision of the implementation = in > this area they might support i.e., there is no way for the Client to > indicate that it will tolerate the Server sending the extension. IMHO = It > is unfortunate version information is not included in each extension. = So > while I agree that this sounds a good move I would be concerned as to t= he > impact on system availability should any Server now be configured to st= art > sending this extension. IMHO I think the horse might have already bolt= ed > in this case :-( >=20 > Mick From Martin.Rex@sap.com Mon Nov 2 06:59:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702A33A657C; Mon, 2 Nov 2009 06:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.047, 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 597Bt2s2X7u1; Mon, 2 Nov 2009 06:59:29 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BF13128C14D; Mon, 2 Nov 2009 06:59:27 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA2Exj5S008421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 15:59:45 +0100 (MET) From: Martin Rex Message-Id: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 2 Nov 2009 15:59:44 +0100 (MET) In-Reply-To: <20091030223647.GO1105@Sun.COM> from "Nicolas Williams" at Oct 30, 9 05:36:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:59:30 -0000 Nicolas Williams wrote: > > Another problem that Larry has is that in his implementation what I call > a "TLS connection" is called a "security context", and if the > application re-handshakes (e.g., to authenticate a user) then the result > is a second security context -- we need to be extra clear that it's the > client Finished message from the _first_ "security context" that we're > after. OooopS. The session that results from a re-handshake is an entirely new and independent session from what it started from, it does NOT modify the state of the original session (as identified by its TLS session ID). Many SSL protocol stacks, however, will perform the re-negotiation with the same "context" or API handle -- giving the application caller impression that the original session is modified. TLS does _NOT_ have capabilities to modify a session, however. It will either resume a cached session as proposed by the client as-is, or it will go through a full handshake and create a new session that is entirely independent from previous sessions. The TLS specs do not describe API semantics, however, only the network protocol and TLS session state, so your terminology is IMHO confusing. > > My proposal, then, is this: > > OLD: > > Description: The client's TLS Finished message (note: the Finished > struct) from the first handshake of the connection (note: connection, > not session, so that the channel binding is specific to each > connection regardless of whether session resumption is used). > > NEW: > > Description: The client's TLS Finished message (note: the Finished > struct) from the first handshake of the application's TLS connection. > > NOTES: > > a) If a session is resumed, the client's TLS Finished message from > the session resumption handshake is to be used; > > b) If a client does multiple TLS handshakes in sequence, each > protected by the previous one, then the client's TLS Finished > message from the first/outermost TLS connection is to be used; > > c) By "TLS connection" we refer to the TLS connection state, not to > any notion of connection of any underlying transport protocols > (such as TCP, UDP, SCTP, etcetera). > > I'm not sure that we can make it any clearer. b) sounds wrong to me. A renegotiate results in a entirely new and independent session. It might be easier to _NOT_ key on the finished message, but on the master secret instead. -Martin From simon@josefsson.org Mon Nov 2 07:55:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279123A6A3D; Mon, 2 Nov 2009 07:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 l5BswaKrYCcm; Mon, 2 Nov 2009 07:55:34 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 116EC3A65A6; Mon, 2 Nov 2009 07:55:33 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nA2FtmIf027506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2009 16:55:50 +0100 From: Simon Josefsson To: mrex@sap.com References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091102:sasl@ietf.org::f95RzMcYqHmcRsGO:4eig X-Hashcash: 1:22:091102:tls@ietf.org::OsgaUW7ykzuMYTtl:IIUW X-Hashcash: 1:22:091102:mrex@sap.com::LD33Omjp0wiguZBd:VOow X-Hashcash: 1:22:091102:channel-binding@ietf.org::ot3ynh3vPUf301aj:MCBX X-Hashcash: 1:22:091102:nicolas.williams@sun.com::A5UJS+zrv3vz5mvf:Zljc Date: Mon, 02 Nov 2009 16:55:48 +0100 In-Reply-To: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 2 Nov 2009 15:59:44 +0100 (MET)") Message-ID: <87hbtcc457.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: channel-binding@ietf.org, sasl@ietf.org, Nicolas Williams , tls@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:55:35 -0000 Martin Rex writes: > It might be easier to _NOT_ key on the finished message, but on the > master secret instead. That was my conclusion as well, hence http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 which uses the TLS PRF interface. For -02 I also added hashing the Finished message, to match the semantics for connection/session (regardless of its definition) of draft-altman-tls-channel-bindings, but I'd prefer to avoid it completely. /Simon From Martin.Rex@sap.com Mon Nov 2 08:34:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0C73A67A5; Mon, 2 Nov 2009 08:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 nIH4OQYLQ2zg; Mon, 2 Nov 2009 08:34:53 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E8E4928C0ED; Mon, 2 Nov 2009 08:34:52 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA2GZBsu001915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 17:35:11 +0100 (MET) From: Martin Rex Message-Id: <200911021635.nA2GZAEp004639@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Mon, 2 Nov 2009 17:35:10 +0100 (MET) In-Reply-To: <87hbtcc457.fsf@mocca.josefsson.org> from "Simon Josefsson" at Nov 2, 9 04:55:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: mrex@sap.com, channel-binding@ietf.org, sasl@ietf.org, Nicolas.Williams@sun.com, tls@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:34:54 -0000 Simon Josefsson wrote: > > Martin Rex writes: > > > It might be easier to _NOT_ key on the finished message, but on the > > master secret instead. > > That was my conclusion as well, hence > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 > which uses the TLS PRF interface. > > For -02 I also added hashing the Finished message, to match the > semantics for connection/session (regardless of its definition) of > draft-altman-tls-channel-bindings, but I'd prefer to avoid it > completely. If you refer to the TLS-extractor interface with TLS PRF, that does unconditionally include the client.random and server.random in the computation and therefore the output will differ for different incarnations (resumes) of the same TLS session. That is comparable to keying to the _most_recent_ finished message -- with __NO__ special cased for TLS session resume and TLS renogiation. -Martin From Martin.Rex@sap.com Mon Nov 2 08:48:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ACB228C129; Mon, 2 Nov 2009 08:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 Fbkr8vx-B1p6; Mon, 2 Nov 2009 08:48:27 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id DE27C28C0ED; Mon, 2 Nov 2009 08:48:26 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA2GmiQQ020042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 17:48:44 +0100 (MET) From: Martin Rex Message-Id: <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 2 Nov 2009 17:48:44 +0100 (MET) In-Reply-To: <20091030223647.GO1105@Sun.COM> from "Nicolas Williams" at Oct 30, 9 05:36:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:48:28 -0000 Nicolas Williams wrote: > > Another problem that Larry has is that in his implementation what I call > a "TLS connection" is called a "security context", and if the > application re-handshakes (e.g., to authenticate a user) then the result > is a second security context -- we need to be extra clear that it's the > client Finished message from the _first_ "security context" that we're > after. Microsoft's implementation (which could be the one referred to by Larry's implementation) has a silly design flaw in its TLS renogiation, and I'm not sure that the previous text is a way to fix it. It is possible to configure Microsoft IIS in a fashion so that it will first perform a TLS handshake with a server-only authentication, and after having received the HTTP request, it will re-negotiate and ask for a client certificate. In the ClientHello, the client will send no TLS session ID (since the purpose is renegotiation -- aka a full TLS handshake. Microsoft IIS will send back a ServerHello with an entirely new TLS session ID. In my TLS clients, I will drop TLS sessions from the client-side cache for which the server asks for re-negotiation (actually replace them with the resulting renegotiated TLS session). Unfortunately, this doesn't save a TLS handshake on the next connect, Microsoft IIS will force another renegotiation when that re-negotiated session is resumed, resulting in yet another new TLS session. >From my experience, it is possible to TLS resume both, the original and the renegotiated session when Microsoft IIS is the server, and it will force through re-negotiation on both. So an IIS configured like that will artificially inflate its server-side session cache and impose unnecessary re-negotiations on the TLS client and on itself. And btw. Channel Binding at the application layer and transparent TLS-session renegotiation at the TLS layer appear somewhere between hard-to-do and mutually exclusive--in case that the TLS session renegotiation happens totally transparent to the application. -Martin From Martin.Rex@sap.com Mon Nov 2 08:56:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B8328C192 for ; Mon, 2 Nov 2009 08:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 dfScEZxOwYQw for ; Mon, 2 Nov 2009 08:56:23 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 9400228C156 for ; Mon, 2 Nov 2009 08:56:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA2GubhT002498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 17:56:37 +0100 (MET) From: Martin Rex Message-Id: <200911021656.nA2Guabb006112@fs4113.wdf.sap.corp> To: mickgray@au1.ibm.com (Michael Gray) Date: Mon, 2 Nov 2009 17:56:36 +0100 (MET) In-Reply-To: from "Michael Gray" at Nov 2, 9 06:50:02 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Server Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:56:24 -0000 Michael Gray wrote: > > > "Michael D'Errico" wrote: > > > There are now at least 3 instances where a TLS client needs to know the > > server's list of supported signature algorithms: > > > > 1. to compute the signature for the CertificateVerify message > > 2. to compute the hash of the handshake messages in (1) without > > having to hold onto all of the messages > > 3. to compute hashes for the proposed cached information extension > > > > Rather than duplicate the list for each of these and any future needs, > > it makes sense to send it once in a server hello extension. > > > > The simplest option would be to use the existing signature algorithms > > extension and make it symmetrical. But if there is a deployed client > > out there that aborts a connection if it receives a signature algorithm > > extension, then a secondary option would be to create a new server- > > signature-algorithms extension which is identical in structure to the > > existing extension. > > > > I would add that when the server sends its list of algorithms in the > > extension, then it MUST NOT send a different list in the certificate > > request message; in fact it SHOULD send an empty list. TLS 1.3 can > > decide whether to eliminate the list from CertificateRequest. > > Currently our toolkit when operating as a client will abort the handshake > on this condition due to RFC 5246 in 7.4.1.4.1 saying: “Servers > MUST NOT send this extension”. That isn't strict, that is anal. It would safe to entirely ignore an extension that should not be present, and this is what the general rule _implies_: "Be liberal in what you accept, be conservative in what you send out." -Martin From wtc@google.com Mon Nov 2 10:02:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE643A6A55 for ; Mon, 2 Nov 2009 10:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 uF0iXZ0vue-6 for ; Mon, 2 Nov 2009 10:02:28 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 400D43A6A51 for ; Mon, 2 Nov 2009 10:02:28 -0800 (PST) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id nA2I2j8m002678 for ; Mon, 2 Nov 2009 18:02:45 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257184967; bh=PqjVPO5aGqG9+fK8MhGxJNZqSxc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ceB+OysO0Uwd6WFq+p6n3VBcF8h7WVBSorSji4cZfvwW2Rtvkr9o8qV9VDjHJVU7P hi/mI6q5Y96qJDIdNBt5Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=cXxLm7FIJsFuIoc7fC6T8kIOQ2hLu4K+efEa0MLUNu/17vbNk2Yb6NKJKdFR0fsqu U2hwM+Jqnyp1NiGXpL64A== Received: from pzk35 (pzk35.prod.google.com [10.243.19.163]) by zps76.corp.google.com with ESMTP id nA2I2LuJ000919 for ; Mon, 2 Nov 2009 10:02:42 -0800 Received: by pzk35 with SMTP id 35so3540848pzk.22 for ; Mon, 02 Nov 2009 10:02:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.25.19 with SMTP id c19mr888148wfj.87.1257184961629; Mon, 02 Nov 2009 10:02:41 -0800 (PST) In-Reply-To: <4AEDFED0.7060505@pobox.com> References: <4AEDFED0.7060505@pobox.com> Date: Mon, 2 Nov 2009 10:02:41 -0800 Message-ID: From: Wan-Teh Chang To: "Michael D'Errico" , Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] Server Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 18:02:29 -0000 On Sun, Nov 1, 2009 at 1:34 PM, Michael D'Errico wrot= e: > So instead of changing the existing signature_algorithms extension, > nothing would break by creating a new server_signature_algorithms > extension. =A0Client support would be advertised by sending an empty > extension to the server. =A0The server would show support by replying > with its list. Michael: I agree this would be the safest solution which eliminates the concern of breaking some TLS 1.2 implementation, at the cost of adding a new TLS extension. This would be an example of a "server-oriented" extension described in Sec. 2.3, page 7 of RFC 4366. Nikos: GnuTLS is one of the first TLS 1.2 implementations. How does GnuTLS deal with this issue now? Does it compute hashes of all the hash algorithms it supports on the handshake messages, or does it buffer the handshake messages until the hash algorithm has been selected? Wan-Teh From n.mavrogiannopoulos@gmail.com Mon Nov 2 11:10:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4FC3A6903 for ; Mon, 2 Nov 2009 11:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 P52WuoDucz9b for ; Mon, 2 Nov 2009 11:10:58 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id CF64728C122 for ; Mon, 2 Nov 2009 11:10:57 -0800 (PST) Received: by bwz23 with SMTP id 23so6688576bwz.29 for ; Mon, 02 Nov 2009 11:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=pRYZt3lYGyUIFENP/msBd4nPuoI7CUC1oTYToZB1bDM=; b=WCTloiJ3bqHkjoS+pM5JAaVbT0oN5nDUZy3Ex+lwNF3rayOQ6SBkHy3uomxV3FR4Uk KAP5dzV7gpK4rUM1SJb//cH72/DAMg8BXSApnwqtmDC7esUt8y9Bow/gUe5EylJRrEc+ 8R5+0Og3CROPVKnWQA9Bl+33G7OUNvBVdzZI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=IDou551JvJXZhEh+/iRSy1mXPd8wbwdiTLNEWEjpGf/w9DA+BMDJ0+El/iGxK2yjJL 10EMb5IwZH0LcYwXoK62sLRm8j/tjW7WHqE584R/b/sDssfj7fXwGXIHdJ2lXz3nyFqu a/TzEy4wUlFJDhOp63MLJFz6m0sA0/PLmGajY= Received: by 10.204.154.203 with SMTP id p11mr4072619bkw.180.1257189074613; Mon, 02 Nov 2009 11:11:14 -0800 (PST) Received: from ?10.100.1.196? (adsl8-169.ath.forthnet.gr [77.49.199.169]) by mx.google.com with ESMTPS id 26sm7457242fks.32.2009.11.02.11.11.13 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Nov 2009 11:11:14 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4AEF2ECF.5020906@gnutls.org> Date: Mon, 02 Nov 2009 21:11:11 +0200 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Wan-Teh Chang References: <4AEDFED0.7060505@pobox.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Server Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 19:10:58 -0000 Wan-Teh Chang wrote: > Nikos: GnuTLS is one of the first TLS 1.2 implementations. > How does GnuTLS deal with this issue now? Does it compute > hashes of all the hash algorithms it supports on the handshake > messages, or does it buffer the handshake messages until > the hash algorithm has been selected? This part was only recently implemented. The current behavior is to not buffer messages in order to keep common code base for all TLS versions (none of the SSL, or TLS protocols so far required such buffering). What we do is hash all the handshake messages with SHA-1 and SHA-256 and hope that those will be among the choices of the server. This works but it is a time bomb. Once one sets up a server that requests some signature algorithm not in this set we do not complete handshake. regards, Nikos From pgut001@wintermute01.cs.auckland.ac.nz Tue Nov 3 01:06:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129F73A6999; Tue, 3 Nov 2009 01:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.564 X-Spam-Level: X-Spam-Status: No, score=-4.564 tagged_above=-999 required=5 tests=[AWL=-1.965, 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 Sw8FJ97M6P8c; Tue, 3 Nov 2009 01:06:36 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 26FBA3A6973; Tue, 3 Nov 2009 01:06:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4E96C9CDBE; Tue, 3 Nov 2009 22:06:40 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp61vi-qjIn8; Tue, 3 Nov 2009 22:06:40 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EC2909CD93; Tue, 3 Nov 2009 22:06:39 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N5FLb-0007Pe-J2; Tue, 03 Nov 2009 22:06:39 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1N5FLb-0003cr-Qk; Tue, 03 Nov 2009 22:06:39 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp> Message-Id: Sender: pgut001 Date: Tue, 03 Nov 2009 22:06:39 +1300 Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:06:37 -0000 Martin Rex writes: >Microsoft's implementation (which could be the one referred to by >Larry's implementation) has a silly design flaw in its TLS renogiation, >and I'm not sure that the previous text is a way to fix it. > >It is possible to configure Microsoft IIS in a fashion so that it >will first perform a TLS handshake with a server-only authentication, >and after having received the HTTP request, it will re-negotiate and >ask for a client certificate. It's not necessarily a design flaw, AFAIK it's a performance optimisation to avoid the server having to maintain state/leave a connection open for an arbitrary amount of time while the user fumbles around with smart cards and certificates and whatnot. Peter. From Martin.Rex@sap.com Tue Nov 3 04:43:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D5D28C17F; Tue, 3 Nov 2009 04:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 dzzVMJkPj1QD; Tue, 3 Nov 2009 04:43:03 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2C54528C149; Tue, 3 Nov 2009 04:43:02 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA3ChHnF008423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Nov 2009 13:43:17 +0100 (MET) From: Martin Rex Message-Id: <200911031243.nA3ChGLw017926@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 3 Nov 2009 13:43:16 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Nov 3, 9 10:06:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 12:43:04 -0000 Peter Gutmann wrote: > > Martin Rex writes: > > >Microsoft's implementation (which could be the one referred to by > >Larry's implementation) has a silly design flaw in its TLS renogiation, > >and I'm not sure that the previous text is a way to fix it. > > > >It is possible to configure Microsoft IIS in a fashion so that it > >will first perform a TLS handshake with a server-only authentication, > >and after having received the HTTP request, it will re-negotiate and > >ask for a client certificate. > > It's not necessarily a design flaw, AFAIK it's a performance optimisation to > avoid the server having to maintain state/leave a connection open for an > arbitrary amount of time while the user fumbles around with smart cards and > certificates and whatnot. I'm sorry if I have explained myself so badly. I was NOT talking about the closing of the connection while the client is prompting the user for selection of a client certificate. That is actually an extremely appreciated feature of MSIE (the Browser), a point where most other web browsers are broken in that they stall the server in the middle of a TLS handshake for an indefinite amount of time while performing user interaction. I was refering to a design flaw in server-side session caching of Microsoft IIS (the Server) when it is configured to perform renegotiation in order to obtain a client certificate after having seen and evaluated the request. -Martin From Nicolas.Williams@sun.com Tue Nov 3 14:35:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F363A6831; Tue, 3 Nov 2009 14:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 FdgmYQNaDAHg; Tue, 3 Nov 2009 14:35:05 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id CB86C3A67D6; Tue, 3 Nov 2009 14:35:05 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA3MZNxi006393; Tue, 3 Nov 2009 22:35:23 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 nA3MZNQN029500; Tue, 3 Nov 2009 15:35: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 nA3MNrrf007585; Tue, 3 Nov 2009 16:23:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3MNrtr007584; Tue, 3 Nov 2009 16:23:53 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 16:23:53 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091103222352.GJ1105@Sun.COM> References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:35:06 -0000 On Mon, Nov 02, 2009 at 03:59:44PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > Another problem that Larry has is that in his implementation what I call > > a "TLS connection" is called a "security context", and if the > > application re-handshakes (e.g., to authenticate a user) then the result > > is a second security context -- we need to be extra clear that it's the > > client Finished message from the _first_ "security context" that we're > > after. > > OooopS. > > The session that results from a re-handshake is an entirely new and > independent session from what it started from, it does NOT modify > the state of the original session (as identified by its TLS session ID). What "oops"? We need to identify one, and only one, client Finished message to use. The name of the thing that that message is related to is only relevant to writing the text for this channel binding type's definition. > Many SSL protocol stacks, however, will perform the re-negotiation > with the same "context" or API handle -- giving the application caller > impression that the original session is modified. TLS does _NOT_ > have capabilities to modify a session, however. It will either > resume a cached session as proposed by the client as-is, or it > will go through a full handshake and create a new session > that is entirely independent from previous sessions. > > The TLS specs do not describe API semantics, however, only the > network protocol and TLS session state, so your terminology is > IMHO confusing. All of that is irrelevant. > > > > My proposal, then, is this: > > > > OLD: > > > > Description: The client's TLS Finished message (note: the Finished > > struct) from the first handshake of the connection (note: connection, > > not session, so that the channel binding is specific to each > > connection regardless of whether session resumption is used). > > > > NEW: > > > > Description: The client's TLS Finished message (note: the Finished > > struct) from the first handshake of the application's TLS connection. > > > > NOTES: > > > > a) If a session is resumed, the client's TLS Finished message from > > the session resumption handshake is to be used; > > > > b) If a client does multiple TLS handshakes in sequence, each > > protected by the previous one, then the client's TLS Finished > > message from the first/outermost TLS connection is to be used; > > > > c) By "TLS connection" we refer to the TLS connection state, not to > > any notion of connection of any underlying transport protocols > > (such as TCP, UDP, SCTP, etcetera). > > > > I'm not sure that we can make it any clearer. > > > b) sounds wrong to me. A renegotiate results in a entirely > new and independent session. That a renegotiate does that is irrelevant. What is relevant is that we want the first Finished message. > It might be easier to _NOT_ key on the finished message, but on the > master secret instead. Too late for that. Nico -- From Nicolas.Williams@sun.com Tue Nov 3 14:36:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215FF3A67D6; Tue, 3 Nov 2009 14:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 xAVHoPWQ4APM; Tue, 3 Nov 2009 14:36:05 -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 0BD6F3A63EB; Tue, 3 Nov 2009 14:36:05 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA3MaL10021489; Tue, 3 Nov 2009 22:36:22 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 nA3MaLa8030140; Tue, 3 Nov 2009 15:36:21 -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 nA3MOpCu007591; Tue, 3 Nov 2009 16:24:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3MOp2A007590; Tue, 3 Nov 2009 16:24:51 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 16:24:51 -0600 From: Nicolas Williams To: Simon Josefsson Message-ID: <20091103222451.GK1105@Sun.COM> References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> <87hbtcc457.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87hbtcc457.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:36:06 -0000 On Mon, Nov 02, 2009 at 04:55:48PM +0100, Simon Josefsson wrote: > Martin Rex writes: > > > It might be easier to _NOT_ key on the finished message, but on the > > master secret instead. > > That was my conclusion as well, hence > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 > which uses the TLS PRF interface. > > For -02 I also added hashing the Finished message, to match the > semantics for connection/session (regardless of its definition) of > draft-altman-tls-channel-bindings, but I'd prefer to avoid it > completely. I don't agree. That it's easier to speak of the master secret is not enough. The Finished message's construction provides better binding of the entire negotiation (up to that Finished message), and that's why we chose it. From Nicolas.Williams@sun.com Tue Nov 3 14:39:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433933A67D6; Tue, 3 Nov 2009 14:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 L0ihQCu1fWuo; Tue, 3 Nov 2009 14:39:27 -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 DB0C63A63EB; Tue, 3 Nov 2009 14:39:26 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA3Mdlwn022230; Tue, 3 Nov 2009 22:39:47 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 nA3MdlEV031945; Tue, 3 Nov 2009 15:39:47 -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 nA3MKkbG007579; Tue, 3 Nov 2009 16:20:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3MKjmI007578; Tue, 3 Nov 2009 16:20:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 16:20:45 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091103222045.GI1105@Sun.COM> References: <200911031243.nA3ChGLw017926@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911031243.nA3ChGLw017926@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:39:28 -0000 On Tue, Nov 03, 2009 at 01:43:16PM +0100, Martin Rex wrote: > Peter Gutmann wrote: > > Martin Rex writes: > > >Microsoft's implementation (which could be the one referred to by > > >Larry's implementation) has a silly design flaw in its TLS renogiation, > > >and I'm not sure that the previous text is a way to fix it. > > > > > >It is possible to configure Microsoft IIS in a fashion so that it > > >will first perform a TLS handshake with a server-only authentication, > > >and after having received the HTTP request, it will re-negotiate and > > >ask for a client certificate. > > > > I was refering to a design flaw in server-side session caching of > Microsoft IIS (the Server) when it is configured to perform renegotiation > in order to obtain a client certificate after having seen and evaluated > the request. Why is that a problem? The request will have named a document, but if you're using confidentiality protection then so what? The client knows the document name, and so does the server. Authorization _correctly_ happens when the access request is made. That the necessary user authentication step is delayed until authorization is needed doesn't strike me as a problem -- it's a feature. After all some documents may have anonymous access, and some may require user authentication. If the server requested user authentication prior to knowing what document the client wants to access, then it will force an ugly interaction on users that only want to access documents that require no user authentication. Nico -- From Nicolas.Williams@sun.com Tue Nov 3 14:49:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185F73A67A8; Tue, 3 Nov 2009 14:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 1R8zGp1AD8iY; Tue, 3 Nov 2009 14:49:49 -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 267FF3A63EB; Tue, 3 Nov 2009 14:49:49 -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 nA3MoANU006199; Tue, 3 Nov 2009 22:50:10 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 nA3Mo9x2037720; Tue, 3 Nov 2009 15:50:09 -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 nA3McdsF007609; Tue, 3 Nov 2009 16:38:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3McdSB007608; Tue, 3 Nov 2009 16:38:39 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 16:38:39 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091103223839.GL1105@Sun.COM> References: <20091030223647.GO1105@Sun.COM> <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:49:50 -0000 On Mon, Nov 02, 2009 at 05:48:44PM +0100, Martin Rex wrote: > And btw. Channel Binding at the application layer and > transparent TLS-session renegotiation at the TLS layer appear > somewhere between hard-to-do and mutually exclusive--in case > that the TLS session renegotiation happens totally transparent > to the application. In order to do channel binding to TLS channels you MUST have some sort of interface to TLS, and that interface MUST let you get at, in this case, the first Finished message (in cleartext) sent by the client. Such an interface necessarily implies that TLS can't be entirely transparent to the application, though some aspects of TLS well might be. Session resumption and re-negotiation complicate how we identify that one message, but they hardly make it impossible. It gets more complicated if a protocol were to multiplex multiple unrelated TLS connections on one TCP/SCTP connection/association. But it's still not impossible: the application, after all, would be keeping track of the various streams and keeping them logically separate. In spite of the _text_ that we need to describe tls-unique being complicated by session resumption and re-negotiation, the actual interfaces and source code will be simple. The complexity is primarily the result of not having a handy word in the TLS terminology for what the Microsoft SSPI interface to TLS calls "security context". If TLS did define such a term, then it'd be easier to specify tls-unique. So far I see no real objections to the actual proposal. Larry objected that the text might make an implementor think that TLS channel bindings are associated with TCP connections. You and Simon would prefer to speak of the Master secret because that doesn't change when you re-negotiate -- but that's hardly enough to change gears now, and then you'd have to bind in things that the Master secret doesn't bind (which would correspondingly complicate your alternative). Let's keep things simple. Please review the proposed text. Nico -- From Martin.Rex@sap.com Tue Nov 3 16:01:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47EA93A6936; Tue, 3 Nov 2009 16:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 MaHHInw4ERKa; Tue, 3 Nov 2009 16:01:41 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 1E0223A686B; Tue, 3 Nov 2009 16:01:40 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA401tk5002236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 01:01:55 +0100 (MET) From: Martin Rex Message-Id: <200911040001.nA401rVh002365@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 4 Nov 2009 01:01:53 +0100 (MET) In-Reply-To: <20091103222045.GI1105@Sun.COM> from "Nicolas Williams" at Nov 3, 9 04:20:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 00:01:42 -0000 Nicolas Williams wrote: > > > > I was refering to a design flaw in server-side session caching of > > Microsoft IIS (the Server) when it is configured to perform renegotiation > > in order to obtain a client certificate after having seen and evaluated > > the request. > > Why is that a problem? The request will have named a document, but if > you're using confidentiality protection then so what? The client knows > the document name, and so does the server. Authorization _correctly_ > happens when the access request is made. That the necessary user > authentication step is delayed until authorization is needed doesn't > strike me as a problem -- it's a feature. You are barking up the wrong tree. The flaw in Microsoft IIS is, that it's server-side session cache is somehow broken. Once it has forced the client through a renegotiate, it should memorize what the client sent as response to the CertificateRequest message (either a client cert or the indication that it doesn't have one or doesn't want to send one). The way it is currently implemented in IIS, it will force the client through a renegotiate on every SSL resume. I never checked how other clients deal with a server that asks them to do a renegotiate in order to ask for a client certificate. Since a renegotiate will ALWAYS result in an entirely new TLS session by performing a full TLS handshake, a sensible client should replace the previously cached session with the re-negotiated one in the client-side cache. A server with a correctly working server-side session cache will find the reply to the CertificateRequest from the regenotiation if that session is later resumed on a new connection and does not need to force a renegotiate when a client proposes a TLS session resume over a new network connection (which is what Microsoft IIS currently does). This strange behaviour of Microsoft IIS only applies for the renegotiation configuration. IIRC, when Microsoft IIS is configured to always ask for the client certificate, it will do so in the initial TLS handshake and correctly use the memorized answer of the client on later TLS session resumes. -Martin From Nicolas.Williams@sun.com Tue Nov 3 16:18:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F843A6A34; Tue, 3 Nov 2009 16:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 alMGzZp79hVp; Tue, 3 Nov 2009 16:18:14 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id C7F3C3A6897; Tue, 3 Nov 2009 16:18:13 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA40IVCF029003; Wed, 4 Nov 2009 00:18:31 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 nA40IUBi021644; Tue, 3 Nov 2009 17:18:31 -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 nA3NxVxQ007665; Tue, 3 Nov 2009 17:59:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3NxUr9007664; Tue, 3 Nov 2009 17:59:30 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 17:59:30 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091103235930.GP1105@Sun.COM> References: <20091103222045.GI1105@Sun.COM> <200911040001.nA401rVh002365@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911040001.nA401rVh002365@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] [CHANNEL-BINDING] Unrelated (Re: RESOLVED (Re: [sasl] lasgt call comments (st Call:) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 00:18:14 -0000 On Wed, Nov 04, 2009 at 01:01:53AM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > Why is that a problem? The request will have named a document, but if > > you're using confidentiality protection then so what? The client knows > > the document name, and so does the server. Authorization _correctly_ > > happens when the access request is made. That the necessary user > > authentication step is delayed until authorization is needed doesn't > > strike me as a problem -- it's a feature. > > You are barking up the wrong tree. > > The flaw in Microsoft IIS is, that it's server-side session cache is > somehow broken. Once it has forced the client through a renegotiate, > it should memorize what the client sent as response to the > CertificateRequest message (either a client cert or the indication > that it doesn't have one or doesn't want to send one). Ah, sure, that sounds like a bug. Nico -- From Martin.Rex@sap.com Tue Nov 3 16:32:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7681828C0FB; Tue, 3 Nov 2009 16:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 YEW5NsrzOqbn; Tue, 3 Nov 2009 16:32:08 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 447BC3A690A; Tue, 3 Nov 2009 16:32:08 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA40WRch023726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 01:32:27 +0100 (MET) From: Martin Rex Message-Id: <200911040032.nA40WQNB004167@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 4 Nov 2009 01:32:26 +0100 (MET) In-Reply-To: <20091103222352.GJ1105@Sun.COM> from "Nicolas Williams" at Nov 3, 9 04:23:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 00:32:09 -0000 Nicolas Williams wrote: > > On Mon, Nov 02, 2009 at 03:59:44PM +0100, Martin Rex wrote: > > Nicolas Williams wrote: > > > > > > Another problem that Larry has is that in his implementation what I call > > > a "TLS connection" is called a "security context", and if the > > > application re-handshakes (e.g., to authenticate a user) then the result > > > is a second security context -- we need to be extra clear that it's the > > > client Finished message from the _first_ "security context" that we're > > > after. > > > > OooopS. > > > > The session that results from a re-handshake is an entirely new and > > independent session from what it started from, it does NOT modify > > the state of the original session (as identified by its TLS session ID). > > What "oops"? We need to identify one, and only one, client Finished > message to use. The name of the thing that that message is related to > is only relevant to writing the text for this channel binding type's > definition. The OooopS refers to the fact, that a TLS session that is renegotiated results in an entirely different TLS session with an independent MasterSecret, and I am violently opposed to having to memorize in the new re-negotiated TLS session anything from a completely unrelated TLS session. A full TLS-handshake and a later TLS session are still the same underlying TLS session, sharing the master secret. (they do have connection-specific and direction specific crypto keys, of course). When a Web Browser loads a new page containing several elements (style sheets, buttons, icons, frames, etc.), then it first needs to retrieve the top level document over a single network connection. Doing so, a new TLS session can be created and added to the session cache. The session can be added to the cache as soon as the TLS handshake is successfully completed, even before any application data has been transferred. Having received the top-level document, the browser determines that it will have to load another dozen or so elements in order to render the page, and will then usually open several network connections in parallel (and probably reuse the one it just used if it is HTTP 1.1 keep-alive). If session caching on both sides is working correctly, then the client can resume the original TLS session on all additional parallel network connections directly. If there is one top-level-page, 12 elements and up to 4 parallel network connections per server, then this will result in a single full TLS handshake and 3 TLS session resumes and one session in the session caches of client and server. 1st page: 1 full, 3 resumes, 1 session in the server session cache 2nd page: 4 resumes, 1 session in the server session cache If your server is a Microsoft IIS with special configuration, then it goes like this: 1 full TLS-handshake plus 1 renegotiate (=1 full TLS-handshake) plus 3 TLS-resumes, each followed by a renegotiate (=3 full TLS-handshakes) 1st page: 5 full, 3 resumes, 5 sessions in the server session cache 2nd page: 4 full, 4 resumes, 9 session in the server session cache A full TLS handshake is typically at least 10x more expensive than a TLS session resume (that is the crypto of the TLS handshake alone, not counting any fancy certificate path validation or revocation checking). > > > > > The TLS specs do not describe API semantics, however, only the > > network protocol and TLS session state, so your terminology is > > IMHO confusing. > > All of that is irrelevant. No, it isn't. With channel bindings, you are actually looking/asking for a particular API semantic. IMHO, a renegotiation is a problem for both TLS PRF ("extractors") and channel bindings, because on the wire and at the TLS protocol level (concerning the TLS session state), renegotiation restarts everything from scratch. It does so under protection of a previously negotiated TLS session, but still, the original and the re-negotiated session are completely distinct and will void all assumptions that the application may have associated with the originally established TLS session. -Martin From Martin.Rex@sap.com Tue Nov 3 17:16:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7143A67A3 for ; Tue, 3 Nov 2009 17:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 GHe-L5QL2SNe for ; Tue, 3 Nov 2009 17:16:11 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id B99783A62C1 for ; Tue, 3 Nov 2009 17:16:10 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA41GUFc019667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 02:16:30 +0100 (MET) From: Martin Rex Message-Id: <200911040116.nA41GTLP006808@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 4 Nov 2009 02:16:29 +0100 (MET) In-Reply-To: <20091103222451.GK1105@Sun.COM> from "Nicolas Williams" at Nov 3, 9 04:24:51 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 01:16:11 -0000 Nicolas Williams wrote: > > On Mon, Nov 02, 2009 at 04:55:48PM +0100, Simon Josefsson wrote: > > Martin Rex writes: > > > > > It might be easier to _NOT_ key on the finished message, but on the > > > master secret instead. > > > > That was my conclusion as well, hence > > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 > > which uses the TLS PRF interface. > > > > For -02 I also added hashing the Finished message, to match the > > semantics for connection/session (regardless of its definition) of > > draft-altman-tls-channel-bindings, but I'd prefer to avoid it > > completely. > > I don't agree. That it's easier to speak of the master secret is not > enough. The Finished message's construction provides better binding of > the entire negotiation (up to that Finished message), and that's why we > chose it. I have not yet understood what semantics you and Larry are actually looking for. Is it (1) about binding to a specific incarnation of a TLS session over one single network connection, then TLS PRF would be OK. Using the Finished message of the TLS handshake (independent of whether it was a full handshake or a resume) would be equivalent. Or is it (2) about binding to a particular full TLS handshake (and the authentication of one of both peers in that full TLS handshake), so that it can be used on several parallel connections and with short interruptions of the network connection, provided that TLS session caching is used and works correctly. TLS session renegotiation reshuffles the cards, so any kind of channel binding or TLS PRF usage must be deferred until the urge for renegotiation among the peers has been fully saturated/quenched to both peers satisfaction. -Martin From Pasi.Eronen@nokia.com Wed Nov 4 06:13:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE333A6359; Wed, 4 Nov 2009 06:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 nut4fQVoqxSK; Wed, 4 Nov 2009 06:13:36 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 432C43A68EA; Wed, 4 Nov 2009 06:13:35 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA4EDOO7001542; Wed, 4 Nov 2009 16:13:54 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:13:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:13:44 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 4 Nov 2009 15:13:43 +0100 From: To: , Date: Wed, 4 Nov 2009 15:13:42 +0100 Thread-Topic: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: Thread-Index: Acpb2oJKfqzhjVd9R8G4op2bkJ4pBABfRgKw Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F7C55FE@NOK-EUMSG-01.mgdnok.nokia.com> References: <87hbtcc457.fsf@mocca.josefsson.org> from "Simon Josefsson" at Nov 2, 9 04:55:48 pm <200911021635.nA2GZAEp004639@fs4113.wdf.sap.corp> In-Reply-To: <200911021635.nA2GZAEp004639@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2009 14:13:44.0184 (UTC) FILETIME=[0476AF80:01CA5D59] X-Nokia-AV: Clean Cc: channel-binding@ietf.org, Nicolas.Williams@sun.com, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 14:13:37 -0000 Martin Rex wrote: > > That was my conclusion as well, hence > > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 > > which uses the TLS PRF interface. > > > > For -02 I also added hashing the Finished message, to match the > > semantics for connection/session (regardless of its definition) of > > draft-altman-tls-channel-bindings, but I'd prefer to avoid it > > completely. >=20 > If you refer to the TLS-extractor interface with TLS PRF, that does > unconditionally include the client.random and server.random in the > computation and therefore the output will differ for different > incarnations (resumes) of the same TLS session. That is comparable > to keying to the _most_recent_ finished message -- with __NO__ > special cased for TLS session resume and TLS renogiation. Note that just extracting some bytes from the TLS master secret (with TLS extractor) is not sufficient to produce a channel binding, because with RSA cipher suites, a man-in-the-middle could cause two TLS sessions to have the same TLS master secret (this is explained in draft-ietf-tls-extractor-07, Section 5). But those two sessions would have different Finished messages. (Version -00 of draft-josefsson-sasl-tls-cb had this problem. Newer versions avoid it by including the handshake messages (either hashed,=20 or via the Finished message) in the calculation.) Best regards, Pasi From Pasi.Eronen@nokia.com Wed Nov 4 06:28:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D733A6900; Wed, 4 Nov 2009 06:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 bdDCWswXTEPT; Wed, 4 Nov 2009 06:28:39 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 348CD3A6852; Wed, 4 Nov 2009 06:28:38 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA4ESTsQ013760; Wed, 4 Nov 2009 16:28:57 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:28:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:28:47 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 4 Nov 2009 15:28:36 +0100 From: To: , Date: Wed, 4 Nov 2009 15:28:35 +0100 Thread-Topic: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) Thread-Index: AcpZsxqWw6nYMK2FSZK/khOlvzWrPgDphhgw Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> In-Reply-To: <20091030223647.GO1105@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2009 14:28:47.0959 (UTC) FILETIME=[1F27CE70:01CA5D5B] X-Nokia-AV: Clean Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 14:28:45 -0000 Nicolas Williams wrote: > My proposal, then, is this: >=20 > OLD: >=20 > Description: The client's TLS Finished message (note: the > Finished struct) from the first handshake of the connection > (note: connection, not session, so that the channel binding is > specific to each connection regardless of whether session > resumption is used). >=20 > NEW: >=20 > Description: The client's TLS Finished message (note: the > Finished struct) from the first handshake of the application's > TLS connection. >=20 > NOTES: >=20 > a) If a session is resumed, the client's TLS Finished message from > the session resumption handshake is to be used; >=20 > b) If a client does multiple TLS handshakes in sequence, each > protected by the previous one, then the client's TLS Finished > message from the first/outermost TLS connection is to be used; >=20 > c) By "TLS connection" we refer to the TLS connection state, not to > any notion of connection of any underlying transport protocols > (such as TCP, UDP, SCTP, etcetera). >=20 > I'm not sure that we can make it any clearer. In any case, I guess we agree that we're referring to the latest TLS handshake sent in clear (with TLS_NULL_WITH_NULL_NULL state)? Could we somehow refer to this? Perhaps: Note: We define a new "TLS connection" to start when the client sends an unencrypted (TLS_NULL_WITH_NULL_NULL cipher suite) Client Hello message (which can lead to either a full handshake, or resuming a session). Renegotiation (sending a Client Hello protected under some other cipher suite) does not start a new "TLS connection". =20 Note that this is separate from any notion of "connection", if any,=20 in the underlying transport protocol (such as TCP or UDP). (Is this consistent with what the existing implementations do?) Best regards, Pasi From Pasi.Eronen@nokia.com Wed Nov 4 06:34:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F3E3A68EC; Wed, 4 Nov 2009 06:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 wztOdza9JLv5; Wed, 4 Nov 2009 06:34:31 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4EAC83A6852; Wed, 4 Nov 2009 06:34:31 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA4EYQC8018760; Wed, 4 Nov 2009 16:34:50 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:34:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:34:40 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 4 Nov 2009 15:34:39 +0100 From: To: , Date: Wed, 4 Nov 2009 15:34:38 +0100 Thread-Topic: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AcpX2mGW8VJUR3NfTRSHi2k9SZOeKAFgQdXQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> In-Reply-To: <87hbtjppfa.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2009 14:34:40.0368 (UTC) FILETIME=[F1352700:01CA5D5B] X-Nokia-AV: Clean Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 14:34:32 -0000 Simon Josefsson wrote: > This reminded me of an earlier observation, and it might be relevant > to re-iterate it here. Consider this: >=20 > Day 1: >=20 > 1. Client establish TLS anon-anon to server. > 2. User authenticates using SCRAM with channel binding to the TLS > channel > 3. User/client disconnects >=20 > Day 2: >=20 > 4. Client resumes the TLS anon-anon connection > 5. Client rehandshake with X.509 client + server authentication > 6. User authenticates using SCRAM with channel binding to the > TLS channel > 7. User/client disconnects >=20 > Day 3: >=20 > 7. Client resumes the TLS session > 8. Client rehandshake it as anon-anon > 9. User authenticates using SCRAM with channel binding to the > TLS channel > 10. User/client disconnects >=20 > With draft-altman-tls-channel-bindings-07, the channel binding data > used in all three SCRAM authentications is the same bit sequence. That certainly was not the intent (the Finished messages used by SCRAM would be from steps 1, 4, and 7 -- and they're all different). Can you check if the latest text proposals (Nico's email on=20 October 30th, starting "I spoke at length with Larry", and=20 my email earlier today) make the situation clearer? Best regards, Pasi From simon@josefsson.org Wed Nov 4 07:18:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5E73A6890; Wed, 4 Nov 2009 07:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=-0.148, 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 GHzR2TYlMRXQ; Wed, 4 Nov 2009 07:18:29 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 75F7E3A67FD; Wed, 4 Nov 2009 07:18:28 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nA4FIiuU017073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2009 16:18:47 +0100 From: Simon Josefsson To: References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091104:sasl@ietf.org::ftW2jU1+B6N6F/C6:1fK+ X-Hashcash: 1:22:091104:larry.zhu@microsoft.com::F7MW4Uwq1Kik7mX5:5qwM X-Hashcash: 1:22:091104:tls@ietf.org::t2M4k3UAgVXRhgn0:Le3I X-Hashcash: 1:22:091104:pasi.eronen@nokia.com::v5vtcQ3FOwHOIInM:B9Go X-Hashcash: 1:22:091104:channel-binding@ietf.org::/2CohyCJGw2UXiv0:ccXw Date: Wed, 04 Nov 2009 16:18:44 +0100 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Wed, 4 Nov 2009 15:34:38 +0100") Message-ID: <87bpjico8b.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 15:18:29 -0000 writes: > Can you check if the latest text proposals (Nico's email on > October 30th, starting "I spoke at length with Larry", and > my email earlier today) make the situation clearer? I have the same question as Martin Rex: what is the actual semantic that is wanted? I thought I understood what was intended, but given this discussion my understanding of what was intended may have been wrong. /Simon From Martin.Rex@sap.com Wed Nov 4 09:27:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F20D28C0EC for ; Wed, 4 Nov 2009 09:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.462 X-Spam-Level: X-Spam-Status: No, score=-5.462 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_05=-1.11, 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 ZlJ76v0awey1 for ; Wed, 4 Nov 2009 09:27:41 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4C67D28C0F6 for ; Wed, 4 Nov 2009 09:27:41 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA4HS1s5007450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Nov 2009 18:28:01 +0100 (MET) From: Martin Rex Message-Id: <200911041728.nA4HS0rd003407@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 4 Nov 2009 18:28:00 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Subject: [TLS] MITM attack on delayed TLS-client auth through renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:27:42 -0000 After elaborating so much about the client cert authentication through renegotiation with Microsoft IIS, I'm beginning to believe that there is a potential security problem with that scheme, because it is susceptible to a MITM attack. How serious the problem is depends on whether and how the client performs the server identification on the renegotiation TLS handshake. The problem: when Microsoft IIS is configured to request a client certificate after having received the request, then it WILL perform an unauthenticated request! Sending the reply back only to the authenticated client is a poor excuse for acting on an unauthenticated request. Attack scenario: sess1 sess2 TLS client <---> rogue TLS server (doing MITM) <---> victim MS IIS The roge TLS server waits for innocent clients to connect and offers to accept the same TLS client certs than the victim MS IIS server. If a TLS client with a promising TLS client cert connects (sess1), then the rogue TLS server establishes an anonymous TLS connection (sess2) with the victim MS IIS server and sends the request it wants performed (URL with command parameters) to the victim MS IIS server-- which replys with a Hello Request asking for a full TLS handshake of an entirely new and independent authenticated TLS session (sess3) At this point, the rogue TLS server starts relaying the TLS handshake messages between the TLS client and the victim MS IIS, i.e. it forwards all handshake messages it receives over sess2 to the client over sess1, and likewise forward all handshake messages it receives over sess1 to the victim MS IIS over sess2. The ChangeCipherSpec is the last Handshake message on each direction that is decrypted/encrypted under the original sess1/sess2 settings, for all further communication, the rogue TLS server (MITM) will forward the incoming network data 1:1 to the other side (because that is protected under keys known only to the TLS client and to the victim MS IIS. The victim MS IIS server has no means to detect that it has been attacked. Whether the TLS client cares about receiving a different TLS server cert in the renegotiation handshake and what it will do about it -- if anything, depends entirely on the application of the TLS client. At the TLS level, everything looks just fine. I'm not sure that all clients will repeat the server authentication. They can be expected to verify the server certificate before sending off their request. Depending on the API architecture, they may not always realize or care that a renegotiation was performed while they were sitting on SSL_read() waiting for the server reply. And even if they decide to perform an additional server endpoint identification, they might be doing it after the renegotiate handshake has been successfully completed -- a point where the victim MS IIS has started performing the action requested in the anonymous request from the MITM. -Martin From Nicolas.Williams@sun.com Wed Nov 4 09:57:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64C03A67B1; Wed, 4 Nov 2009 09:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 9Fx8eWbggz7d; Wed, 4 Nov 2009 09:57:35 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id C354F3A67E5; Wed, 4 Nov 2009 09:57:34 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA4Hveva000731; Wed, 4 Nov 2009 17:57:52 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 nA4HvdMV042877; Wed, 4 Nov 2009 10:57:39 -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 nA4HkAkk008243; Wed, 4 Nov 2009 11:46:10 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4Hk9oF008242; Wed, 4 Nov 2009 11:46:09 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 11:46:09 -0600 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20091104174609.GW1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:57:35 -0000 On Wed, Nov 04, 2009 at 03:28:35PM +0100, Pasi.Eronen@nokia.com wrote: > Nicolas Williams wrote: > > I'm not sure that we can make it any clearer. > > In any case, I guess we agree that we're referring to the latest TLS > handshake sent in clear (with TLS_NULL_WITH_NULL_NULL state)? Yes (and before any ChangeCipherSpec messages). > Could we somehow refer to this? Perhaps: > > Note: We define a new "TLS connection" to start when the client > sends an unencrypted (TLS_NULL_WITH_NULL_NULL cipher suite) Client > Hello message (which can lead to either a full handshake, or > resuming a session). Renegotiation (sending a Client Hello protected > under some other cipher suite) does not start a new "TLS connection". > Note that this is separate from any notion of "connection", if any, > in the underlying transport protocol (such as TCP or UDP). I like that. > (Is this consistent with what the existing implementations do?) It's consistent with the description that had been registered. I don't have an implementation, so I can't say as to existing implementations. Jeff and/or Larry should know. Nico -- From Nicolas.Williams@sun.com Wed Nov 4 10:06:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E3F3A691D; Wed, 4 Nov 2009 10:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 nQIP4XF4ft5L; Wed, 4 Nov 2009 10:06:50 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id E2BDD3A6922; Wed, 4 Nov 2009 10:06:49 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4I77us018389; Wed, 4 Nov 2009 18:07:07 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 nA4I77uk050114; Wed, 4 Nov 2009 11:07:07 -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 nA4HtcTm008250; Wed, 4 Nov 2009 11:55:38 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4HtbZ0008249; Wed, 4 Nov 2009 11:55:37 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 11:55:37 -0600 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20091104175537.GX1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.7i Cc: simon@josefsson.org, channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:06:51 -0000 On Wed, Nov 04, 2009 at 03:34:38PM +0100, Pasi.Eronen@nokia.com wrote: > Simon Josefsson wrote: > > This reminded me of an earlier observation, and it might be relevant > > to re-iterate it here. Consider this: > > > > Day 1: > > > > 1. Client establish TLS anon-anon to server. > > 2. User authenticates using SCRAM with channel binding to the TLS > > channel > > 3. User/client disconnects > > > > Day 2: > > > > 4. Client resumes the TLS anon-anon connection > > 5. Client rehandshake with X.509 client + server authentication > > 6. User authenticates using SCRAM with channel binding to the > > TLS channel > > 7. User/client disconnects > > > > Day 3: > > > > 7. Client resumes the TLS session > > 8. Client rehandshake it as anon-anon > > 9. User authenticates using SCRAM with channel binding to the > > TLS channel > > 10. User/client disconnects > > > > With draft-altman-tls-channel-bindings-07, the channel binding data > > used in all three SCRAM authentications is the same bit sequence. > > That certainly was not the intent (the Finished messages used by > SCRAM would be from steps 1, 4, and 7 -- and they're all different). Indeed, that's absolutely not the intent. The intent is that you use the first client Finished message sent on each of those "connections". Note, incidentally, that Simon's view of how tls-unique was intended to work, would not be flawed, cryptographically. It wouldn't interoperate with other implementations, and it'd be hard to implement (since it means updating saved session state). It would conflict the very name of the channel binding type and it's description as being a "unique" channel binding type in the RFC5056 sense -- that should be the biggest clue that Simon's interpretation is incorrect. I have a very, very hard time understanding how this might not by now be clear. It doesn't help that TLS doesn't have a name for the entity from which we're extracting the channel binding, but that's the only real problem here. I also have a very, very hard time understanding how the previous text could have led anyone to think that TCP connection state should track TLS channel binding data. RFC5246 may not have a name for the entity... but it does speak of "TLS connections", which you can see from the naming of section 6.1: "Connection States". Nonetheless I'm happy to revise text to make this matter clearer. I'd be happy even to introduce text naming that entity which RFC5246 does not name. Nico -- From mike-list@pobox.com Wed Nov 4 10:23:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6043928C106; Wed, 4 Nov 2009 10:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 To94f-FM7qfE; Wed, 4 Nov 2009 10:23:42 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 7468928C0FF; Wed, 4 Nov 2009 10:23:41 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 60EB9734F0; Wed, 4 Nov 2009 13:24:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=QZXsTlABM3zx u1/bNkv3znArCIo=; b=fX9GUPbAqn4NLJDeryIWGzDCKqLefxxDBdptipEJUknO NVyVwJ7fiCXwpMYXoxeZFytuKgKDaUnqeyrQW4hmVJ3Ag5YobQNkguVg0k6aFKCC lLExs5CXlo8jXfIpDz5GPLQxPyrTaSvnph5GgYkKhFlo6Q4hJWRHYABVfeiXPBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=C7SvV7 gZ1lgp86gAGaXGtAWwABbIxwleeRNlae+zbO6iugXz7Z7xHkUFFQ1WoGgns9zLZJ 19IEzjicjuDovbgeFxYK65o5PAH5QrpJhQnGrtp/Q/JGQ3j7NfFRlRAiK6IKa/Nl mO47vP13w+nH9zPXw2HTmGwCyHXj34O3JC4rQ= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 43069734EF; Wed, 4 Nov 2009 13:24:00 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 7EA3F734EE; Wed, 4 Nov 2009 13:23:56 -0500 (EST) Message-ID: <4AF1C6DD.7030502@pobox.com> Date: Wed, 04 Nov 2009 10:24:29 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: channel-binding@ietf.org, tls@ietf.org References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 38FE9ABA-C96F-11DE-B1CA-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Cc: sasl@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:23:43 -0000 I don't pretend to know exactly what this feature is supposed to do, but I think using the word "connection" would be a mistake given its widespread use meaning TCP connections, etc. Perhaps using a different word such as "link" would portray the meaning you want without causing confusion? Mike > Could we somehow refer to this? Perhaps: > > Note: We define a new "TLS connection" to start when the client > sends an unencrypted (TLS_NULL_WITH_NULL_NULL cipher suite) Client > Hello message (which can lead to either a full handshake, or > resuming a session). Renegotiation (sending a Client Hello protected > under some other cipher suite) does not start a new "TLS connection". > Note that this is separate from any notion of "connection", if any, > in the underlying transport protocol (such as TCP or UDP). > > (Is this consistent with what the existing implementations do?) > > Best regards, > Pasi From Nicolas.Williams@sun.com Wed Nov 4 10:24:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369A928C0DB; Wed, 4 Nov 2009 10:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 cFzyz6RbV5ib; Wed, 4 Nov 2009 10:24:06 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 48FBF28C115; Wed, 4 Nov 2009 10:24:05 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4IOR1C003545; Wed, 4 Nov 2009 18:24:27 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 nA4IOQ3P064769; Wed, 4 Nov 2009 11:24:27 -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 nA4ICwiG008262; Wed, 4 Nov 2009 12:12:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4ICwiu008261; Wed, 4 Nov 2009 12:12:58 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 12:12:58 -0600 From: Nicolas Williams To: Simon Josefsson Message-ID: <20091104181257.GY1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> <87bpjico8b.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bpjico8b.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:24:07 -0000 On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote: > writes: > > > Can you check if the latest text proposals (Nico's email on > > October 30th, starting "I spoke at length with Larry", and > > my email earlier today) make the situation clearer? > > I have the same question as Martin Rex: what is the actual semantic that > is wanted? I thought I understood what was intended, but given this > discussion my understanding of what was intended may have been wrong. The desired semantic is that tls-unique channel bindings are a channel binding in the RFC5056 sense, for a "TLS channel", with this particular feature (from the I-D): o Channel binding type: unique (which RFC5056 defines). Was this not utterly clear already? How could it not have been? The only possible point of contention from the above description is just what a "TLS channel" might be. And the only reasons for that are: - RFC5246 and predecessors don't define a name for what we've been calling a "TLS connection"; - Session resumption might cause someone to be confused and think that tls-unique refers to the client's Finished message from the resumed session; - Re-negotiation might cause someone to be confused and think that tls-unique refers to the client's Finished message from the re-negotiated "TLS connection". Let's dispose of these for once and for all: - We shall use "TLS connection" to refer to the TLS state created by an exchange beginning with a Client Hello message, followed by a TLS handshake sequence (which involves a ServerHello, a variety of optional messages such as Certificate, and ends in an optional ChangeCipherSpec message exchange) followed by an exchange of Finished messages. - Session resumption establishes new state as per the previous definition of "TLS connection", therefore it establishes a new "TLS connection", even though session resumption does NOT establish a new session. Therefore, the tls-unique channel binding for a "TLS connection" that resumes a session, MUST be the client's Finished message from the new connection, not the old session. - Re-negotiation consists of initiating a new "TLS connection" while using another "TLS connection" record layer for integrity (and usually also confidentiality) protection of the re-negotiation. As such re-negotiation creates a new "TLS connection". In this case want the tls-unique channel binding to be used by the application to be that of the first "TLS connection", that is, the one whose ClientHello and handshake were not protected by any other "TLS connection". (It follows that even if the client does N re-negotiations, where N > 2, we still want the application to use the tls-unique channel binding of the first "TLS connection", the one whose handshake was not protected by any other "TLS connection".) Therefore a "TLS channel" is really: a "TLS connection", as defined above, whose handshake was not protected by any other "TLS connection". This is a significantly more rigorous description than the ones we've discussed so far. Do you agree that it's air-tight? Should I propose new text that adds the above definitions of "TLS connection" and "TLS channel"? I think I should, so I will, shortly. Nico -- From Nicolas.Williams@sun.com Wed Nov 4 10:30:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23133A67B0 for ; Wed, 4 Nov 2009 10:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 xaGWR7m7oV8v for ; Wed, 4 Nov 2009 10:30:16 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id A9D103A62C1 for ; Wed, 4 Nov 2009 10:30:16 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4IUb7m011778 for ; Wed, 4 Nov 2009 18:30:37 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 nA4IUauX003722 for ; Wed, 4 Nov 2009 11:30:37 -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 nA4IJ8Wu008272; Wed, 4 Nov 2009 12:19:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4IJ8T2008271; Wed, 4 Nov 2009 12:19:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 12:19:08 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091104181907.GZ1105@Sun.COM> References: <20091103222451.GK1105@Sun.COM> <200911040116.nA41GTLP006808@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911040116.nA41GTLP006808@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:30:18 -0000 On Wed, Nov 04, 2009 at 02:16:29AM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Mon, Nov 02, 2009 at 04:55:48PM +0100, Simon Josefsson wrote: > > > Martin Rex writes: > > > > > > > It might be easier to _NOT_ key on the finished message, but on the > > > > master secret instead. > > > > > > That was my conclusion as well, hence > > > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 > > > which uses the TLS PRF interface. > > > > > > For -02 I also added hashing the Finished message, to match the > > > semantics for connection/session (regardless of its definition) of > > > draft-altman-tls-channel-bindings, but I'd prefer to avoid it > > > completely. > > > > I don't agree. That it's easier to speak of the master secret is not > > enough. The Finished message's construction provides better binding of > > the entire negotiation (up to that Finished message), and that's why we > > chose it. > > > I have not yet understood what semantics you and Larry are actually > looking for. The desired semantic is that tls-unique channel bindings are a channel binding in the RFC5056 sense, for a "TLS channel", with this particular feature (from the I-D): o Channel binding type: unique (which RFC5056 defines). See my follow-up, just now, that begins with that same text. > Is it (1) > about binding to a specific incarnation of a TLS session > over one single network connection, then TLS PRF would be OK. > Using the Finished message of the TLS handshake (independent > of whether it was a full handshake or a resume) would be > equivalent. The latter: the client's Finished message from a handshake that is not protected by any other TLS connection, and regardless of whether the handshake is a session resumption handshake. > Or is it (2) > about binding to a particular full TLS handshake (and the > authentication of one of both peers in that full TLS handshake), > so that it can be used on several parallel connections and with short > interruptions of the network connection, provided that TLS session > caching is used and works correctly. No. This is not about whether the client or server are authenticated. Authentication in the TLS layer is irrelevant to the channel binding. We want to be able to bind to anon-anon TLS connections. > TLS session renegotiation reshuffles the cards, so any kind of > channel binding or TLS PRF usage must be deferred until > the urge for renegotiation among the peers has been fully > saturated/quenched to both peers satisfaction. Re-negotiation is not an issue: it suffices to use a channel binding for the "first" connection, meaning: a connection whose handshake is not protected by another connection, and NOT meaning: the one that established a session that is being resumed. From Nicolas.Williams@sun.com Wed Nov 4 10:38:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBFF3A68CB; Wed, 4 Nov 2009 10:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 F7V1T7EvW6gp; Wed, 4 Nov 2009 10:38:18 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 355453A67AF; Wed, 4 Nov 2009 10:38:12 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA4IcXEo015656; Wed, 4 Nov 2009 18:38:34 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 nA4IcXeM009722; Wed, 4 Nov 2009 11:38: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 nA4IR4jc008279; Wed, 4 Nov 2009 12:27:04 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4IR4if008278; Wed, 4 Nov 2009 12:27:04 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 12:27:04 -0600 From: Nicolas Williams To: "Michael D'Errico" Message-ID: <20091104182704.GA1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> <4AF1C6DD.7030502@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF1C6DD.7030502@pobox.com> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:38:18 -0000 On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote: > I don't pretend to know exactly what this feature is supposed to do, > but I think using the word "connection" would be a mistake given its > widespread use meaning TCP connections, etc. At least the word 'connection' is used in RFC5246 _some_ times to mean what we were using it to mean here. > Perhaps using a different word such as "link" would portray the > meaning you want without causing confusion? 'Link' is even worse. We'll probably have to include our own definition in the I-D. The fact that certain words are overloaded does not mean that they cannot be used. This is a fact of life in Internet standards, that terminology varies significantly, and often overlaps, between areas, and even within areas. One way to avoid confusion is to indicate, in each context, the source of one's terminology, and to clarify whenever one must refer to multiple documents with conflicting terminologies. Another way is to invent new terminology whenever conflicts arise. The latter is very difficult to do and to popularize. The former requires discipline. I prefer the former. From jhutz@cmu.edu Wed Nov 4 10:14:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396B53A68EA; Wed, 4 Nov 2009 10:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-1.133, 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 2iV0udUmxLQ3; Wed, 4 Nov 2009 10:14:22 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 778283A6801; Wed, 4 Nov 2009 10:14:22 -0800 (PST) Received: from [10.0.0.3] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nA4IEfnY025637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 13:14:41 -0500 (EST) Date: Wed, 04 Nov 2009 13:14:41 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , mrex@sap.com Message-ID: <754BFABD8F4175F04918E805@atlantis.pc.cs.cmu.edu> In-Reply-To: <11983_1257287730_nA3MZT4b001736_20091103222352.GJ1105@Sun.COM> References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> <11983_1257287730_nA3MZT4b001736_20091103222352.GJ1105@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 X-Mailman-Approved-At: Wed, 04 Nov 2009 10:46:10 -0800 Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org, jhutz@cmu.edu Subject: Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:14:23 -0000 --On Tuesday, November 03, 2009 04:23:53 PM -0600 Nicolas Williams wrote: >> It might be easier to _NOT_ key on the finished message, but on the >> master secret instead. > > Too late for that. Not just too late, but also a bad idea. Previous discussions relating to FAST and anonymous PKINIT resulted in some investigation which, in turn, led to the somewhat surprising result that the TLS master secret does _not_ name a unique channel, while the finished messages _do_. -- Jeff From hartmans@mit.edu Wed Nov 4 11:00:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804CE3A6914; Wed, 4 Nov 2009 11:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 H95GKtKOJyTe; Wed, 4 Nov 2009 11:00:05 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id ACBD53A6911; Wed, 4 Nov 2009 11:00:05 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 57C3920205; Wed, 4 Nov 2009 14:00:23 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2E52643BE; Wed, 4 Nov 2009 14:00:20 -0500 (EST) To: Nicolas Williams References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> <4AF1C6DD.7030502@pobox.com> <20091104182704.GA1105@Sun.COM> From: Sam Hartman Date: Wed, 04 Nov 2009 14:00:20 -0500 In-Reply-To: <20091104182704.GA1105@Sun.COM> (Nicolas Williams's message of "Wed\, 4 Nov 2009 12\:27\:04 -0600") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:00:06 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote: >> I don't pretend to know exactly what this feature is supposed >> to do, but I think using the word "connection" would be a >> mistake given its widespread use meaning TCP connections, etc. Nicolas> At least the word 'connection' is used in RFC5246 _some_ Nicolas> times to mean what we were using it to mean here. Sanity check here: For the most part, there is a one-to-one mapping between what we're talking about and TCP connections, right? In particular, for most applications, even applications with multiple finish messages, grabbing the first finish message from a TCP connection gives exactly the one we want. Am I correctly understanding our goal? If so, this sounds fairly pedantic. Pedantic is not bad--we should get it to be correct. However for most app developers, it seems that if they assume connection means tcp connection, the right thing will happen. If that's not true, then we have a lot of explaining to do, because if I'm confused, then this is a hard problem to explain. From Nicolas.Williams@sun.com Wed Nov 4 11:16:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAEE3A67D1; Wed, 4 Nov 2009 11:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 Da+PqbqLExUY; Wed, 4 Nov 2009 11:16:37 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id CF8C73A68C1; Wed, 4 Nov 2009 11:16:36 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4JGwpH005532; Wed, 4 Nov 2009 19:16:58 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 nA4JGwMA037327; Wed, 4 Nov 2009 12:16:58 -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 nA4J5R1p008329; Wed, 4 Nov 2009 13:05:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4J5RLb008328; Wed, 4 Nov 2009 13:05:27 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 13:05:27 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20091104190526.GB1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> <4AF1C6DD.7030502@pobox.com> <20091104182704.GA1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:16:37 -0000 On Wed, Nov 04, 2009 at 02:00:20PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote: > >> I don't pretend to know exactly what this feature is supposed > >> to do, but I think using the word "connection" would be a > >> mistake given its widespread use meaning TCP connections, etc. > > Nicolas> At least the word 'connection' is used in RFC5246 _some_ > Nicolas> times to mean what we were using it to mean here. > > Sanity check here: For the most part, there is a one-to-one mapping > between what we're talking about and TCP connections, right? In For the most part, yes. > particular, for most applications, even applications with multiple > finish messages, grabbing the first finish message from a TCP > connection gives exactly the one we want. Am I correctly > understanding our goal? Yes. > If so, this sounds fairly pedantic. Pedantic is not bad--we should > get it to be correct. However for most app developers, it seems that > if they assume connection means tcp connection, the right thing will > happen. If that's not true, then we have a lot of explaining to do, > because if I'm confused, then this is a hard problem to explain. You're not confused. I fully agree that we've gotten pedantic here. I don't really understand how anyone could have thought that the channel binding needed to be communicated to TCP, and thence to the application, but that's how we got to this point. Now that we're here, I think we might as well consider whether we want to have extra rigorous text, or whether we approve the document as is. Nico -- From simon@josefsson.org Wed Nov 4 11:26:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254DD3A68E7; Wed, 4 Nov 2009 11:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 cUoplztkeEdB; Wed, 4 Nov 2009 11:26:13 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D05A73A67B6; Wed, 4 Nov 2009 11:26:12 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nA4JQUKj022658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2009 20:26:32 +0100 From: Simon Josefsson To: Nicolas Williams References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> <87bpjico8b.fsf@mocca.josefsson.org> <20091104181257.GY1105@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091104:tls@ietf.org::E+MsoNkDbZ0j/YBl:0Uvi X-Hashcash: 1:22:091104:nicolas.williams@sun.com::n3HUsOfNYddl4ZyB:1bDE X-Hashcash: 1:22:091104:channel-binding@ietf.org::RXChJT0iKFtgtKX5:2Ceb X-Hashcash: 1:22:091104:sasl@ietf.org::4t7yvQqTduGLQQSN:LgVb Date: Wed, 04 Nov 2009 20:26:30 +0100 In-Reply-To: <20091104181257.GY1105@Sun.COM> (Nicolas Williams's message of "Wed, 4 Nov 2009 12:12:58 -0600") Message-ID: <87aaz2jdll.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:26:14 -0000 Nicolas Williams writes: > On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote: >> writes: >> >> > Can you check if the latest text proposals (Nico's email on >> > October 30th, starting "I spoke at length with Larry", and >> > my email earlier today) make the situation clearer? >> >> I have the same question as Martin Rex: what is the actual semantic that >> is wanted? I thought I understood what was intended, but given this >> discussion my understanding of what was intended may have been wrong. > > The desired semantic is that tls-unique channel bindings are a channel > binding in the RFC5056 sense, for a "TLS channel", with this particular > feature (from the I-D): > > o Channel binding type: unique > > (which RFC5056 defines). > > Was this not utterly clear already? How could it not have been? > > The only possible point of contention from the above description is just > what a "TLS channel" might be. And the only reasons for that are: > > - RFC5246 and predecessors don't define a name for what we've been > calling a "TLS connection"; > > - Session resumption might cause someone to be confused and think that > tls-unique refers to the client's Finished message from the resumed > session; > > - Re-negotiation might cause someone to be confused and think that > tls-unique refers to the client's Finished message from the > re-negotiated "TLS connection". > > Let's dispose of these for once and for all: > > - We shall use "TLS connection" to refer to the TLS state created by an > exchange beginning with a Client Hello message, followed by a TLS > handshake sequence (which involves a ServerHello, a variety of > optional messages such as Certificate, and ends in an optional > ChangeCipherSpec message exchange) followed by an exchange of > Finished messages. > > - Session resumption establishes new state as per the previous > definition of "TLS connection", therefore it establishes a new "TLS > connection", even though session resumption does NOT establish a new > session. Therefore, the tls-unique channel binding for a "TLS > connection" that resumes a session, MUST be the client's Finished > message from the new connection, not the old session. > > - Re-negotiation consists of initiating a new "TLS connection" while > using another "TLS connection" record layer for integrity (and > usually also confidentiality) protection of the re-negotiation. > > As such re-negotiation creates a new "TLS connection". In this case > want the tls-unique channel binding to be used by the application to > be that of the first "TLS connection", that is, the one whose > ClientHello and handshake were not protected by any other "TLS > connection". > > (It follows that even if the client does N re-negotiations, where N > > 2, we still want the application to use the tls-unique channel > binding of the first "TLS connection", the one whose handshake was > not protected by any other "TLS connection".) > > Therefore a "TLS channel" is really: a "TLS connection", as defined > above, whose handshake was not protected by any other "TLS connection". > > This is a significantly more rigorous description than the ones we've > discussed so far. Do you agree that it's air-tight? Should I propose > new text that adds the above definitions of "TLS connection" and "TLS > channel"? I think I should, so I will, shortly. With that definition, one couldn't use tls-unique channel binding to bind to the authentication credentials associated with a TLS channel uniquely -- a TLS re-negotiation doesn't change the channel binding data, but it may change the authentication credentials. I believe that problem needs to be explained in the security consideration -- it would be easy to think that channel binding data can be used to get a cryptographic association with the user credentials used for that channel. Otherwise I don't see any problem with this definition. /Simon From Nicolas.Williams@sun.com Wed Nov 4 12:03:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778963A6A0A; Wed, 4 Nov 2009 12:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 cnDhrML3e5Sn; Wed, 4 Nov 2009 12:03:19 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 79B8B3A6A09; Wed, 4 Nov 2009 12:03:19 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA4K3dpJ009470; Wed, 4 Nov 2009 20:03:39 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 nA4K3cZQ003091; Wed, 4 Nov 2009 13:03:39 -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 nA4Jq9Mv008352; Wed, 4 Nov 2009 13:52:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4Jq8hG008351; Wed, 4 Nov 2009 13:52:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 13:52:08 -0600 From: Nicolas Williams To: Simon Josefsson Message-ID: <20091104195208.GD1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> <87bpjico8b.fsf@mocca.josefsson.org> <20091104181257.GY1105@Sun.COM> <87aaz2jdll.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87aaz2jdll.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:03:20 -0000 On Wed, Nov 04, 2009 at 08:26:30PM +0100, Simon Josefsson wrote: > Nicolas Williams writes: > > [...] > > With that definition, one couldn't use tls-unique channel binding to > bind to the authentication credentials associated with a TLS channel ^^^^^^^^^^^^^^^^^^^^^^^^^^ > uniquely -- a TLS re-negotiation doesn't change the channel binding > data, but it may change the authentication credentials. The point of channel binding is NOT to bind the authentication credentials of the channel's end-points. In fact, the point of channel binding is to allow authentication to happen at a layer above the channel, so that the authentication, or lack thereof in that channel, becomes irrelevant. Please see RFC5056. > I believe that problem needs to be explained in the security > consideration -- it would be easy to think that channel binding data can > be used to get a cryptographic association with the user credentials > used for that channel. There is no problem. > Otherwise I don't see any problem with this definition. Thanks. Nico -- From jsalowey@cisco.com Wed Nov 4 13:43:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A2D3A68B3 for ; Wed, 4 Nov 2009 13:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Oc-g1b232hax for ; Wed, 4 Nov 2009 13:42:59 -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 2302E3A686C for ; Wed, 4 Nov 2009 13:42:59 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKqE8UqrR7H+/2dsb2JhbADGb5d6hD0E X-IronPort-AV: E=Sophos;i="4.44,682,1249257600"; d="scan'208";a="424949135" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 04 Nov 2009 21:43:21 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA4LhLnr017247 for ; Wed, 4 Nov 2009 21:43:21 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 13:43:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 13:43:20 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interest in taking draft-seggelmann-tls-dtls-heartbeat-01 as a working group item Thread-Index: Acpdl9NgJElUwV+2Q9+kk6c8I0NEiA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 04 Nov 2009 21:43:21.0060 (UTC) FILETIME=[D3EF4A40:01CA5D97] Subject: [TLS] Interest in taking draft-seggelmann-tls-dtls-heartbeat-01 as a working group item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 21:43:00 -0000 There has been some interest expressed in draft-seggelmann-tls-dtls-heartbeat. I'd like to see if there is enough to take this up as a TLS working group item. Please respond if you approve or disapprove taking this on as a working group item. If you approve please indicate if you are willing to contribute text or review. Thanks, Joe From larry.zhu@microsoft.com Wed Nov 4 14:13:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DF83A68B3; Wed, 4 Nov 2009 14:13:27 -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 f19SG883+Ot1; Wed, 4 Nov 2009 14:13:26 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 45BB83A688D; Wed, 4 Nov 2009 14:13:26 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 14:14:03 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.20; Wed, 4 Nov 2009 14:13:47 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 4 Nov 2009 14:13:48 -0800 From: Larry Zhu To: Nicolas Williams Thread-Topic: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) Thread-Index: AQHKWbNKKo89XNrhrEC3HCaJjhtWGJEmhAyA Date: Wed, 4 Nov 2009 22:13:46 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> In-Reply-To: <20091030223647.GO1105@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 22:13:27 -0000 The proposed looks fine. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicol= as Williams Sent: Friday, October 30, 2009 3:37 PM To: Larry Zhu Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-alt= man-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) I spoke at length with Larry. His concern is that the word "conenction" might be taken to mean "TCP connection" or "connection for the transport below TLS". Clearly it is not reasonable to expect to extract the TLS channel binding from the "connection for the transport below TLS"! Larry's proposal to say "session" was only to make that confusion go away, but that proposal is very difficult to implement (as I described separately already). Larry has indicated to me (and I expect will indicate on the list in reply to this email) that he will be happy if we simply clarify that "TLS connection" refers to the TLS state, NOT to the transport below. Unfortunately RFC5246 does not seem to have a term by which to refer the "TLS connection" unambiguously: "connection" is defined in the glossary (page 80) to mean that which Larry doesn't want (underlying transport), but then, in section 6.1 RFC5246 quite clearly uses the word "connection" to refer to "TLS connection", not to the underlying transport. Thus this is a simple matter of wordsmithing. Another problem that Larry has is that in his implementation what I call a "TLS connection" is called a "security context", and if the application re-handshakes (e.g., to authenticate a user) then the result is a second security context -- we need to be extra clear that it's the client Finished message from the _first_ "security context" that we're after. My proposal, then, is this: OLD: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the connection (note: connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). NEW: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the application's TLS connection. NOTES: a) If a session is resumed, the client's TLS Finished message from the session resumption handshake is to be used; b) If a client does multiple TLS handshakes in sequence, each protected by the previous one, then the client's TLS Finished message from the first/outermost TLS connection is to be used; c) By "TLS connection" we refer to the TLS connection state, not to any notion of connection of any underlying transport protocols (such as TCP, UDP, SCTP, etcetera). I'm not sure that we can make it any clearer. Larry, please review. Martin, please review. Nico --=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Wed Nov 4 14:13:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDE23A68B3 for ; Wed, 4 Nov 2009 14:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.283 X-Spam-Level: X-Spam-Status: No, score=-0.283 tagged_above=-999 required=5 tests=[AWL=2.317, 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 WtNo6Ilk6cYy for ; Wed, 4 Nov 2009 14:13:24 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 9DC9F3A688D for ; Wed, 4 Nov 2009 14:13:24 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N5o6s-000DG5-7Q for tls@ietf.org; Wed, 04 Nov 2009 22:13:46 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 36AAD6674 for ; Wed, 4 Nov 2009 22:13:45 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+QxlZ3re26BRwjx9H9aTGUYmSPS3ctKGo= Message-ID: <4AF1FC99.3040204@extendedsubset.com> Date: Wed, 04 Nov 2009 16:13:45 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] MITM attack on delayed TLS-client auth through renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 22:13:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello TLS, I can confirm the severity of the TLS MITM bug. I've had a working exploit going since the end of August. Steve Dispensa and myself put together (with help of many of course) an industry working group to address it. I think we were successful in producing a preliminary fix, which vendors are in various stages of testing and deployment. We'd agreed to responsibly delay disclosure to give the industry time to coordinate the fix. I've watched with excitement as the TLS Channel Binding work uncovered it. Kudos to Martin Rex for his description of the basic problem. I'll be putting the bulk of our research to this point on my blog this afternoon. http://extendedsubset.com/ This will include documentation, diagrams, packet captures...pretty much everything short of exploit code. I suspect that some relevant industry groups will be releasing some information. Also, the company I work at, PhoneFactor, will probably be doing some type of informational release soon. Regards, Marsh Ray -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrx/JgACgkQWChJ3x422/LxfwCeKc/UegM9/HSdtv8ymCDnNeOd SI8AnAnVLgwht3K21aHSlAUrjow5QPh+ =dMtp -----END PGP SIGNATURE----- From Nicolas.Williams@sun.com Wed Nov 4 14:43:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D8628C156 for ; Wed, 4 Nov 2009 14:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 vFEah5nqbIqb for ; Wed, 4 Nov 2009 14:43:50 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id AFA7A28C149 for ; Wed, 4 Nov 2009 14:43:50 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4MiCCd013009 for ; Wed, 4 Nov 2009 22:44:12 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 nA4MiBWh011253 for ; Wed, 4 Nov 2009 15:44:11 -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 nA4MWgd7008654; Wed, 4 Nov 2009 16:32:42 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4MWgPh008653; Wed, 4 Nov 2009 16:32:42 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 16:32:42 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091104223242.GL1105@Sun.COM> References: <200911041728.nA4HS0rd003407@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911041728.nA4HS0rd003407@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] MITM attack on delayed TLS-client auth through renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 22:43:52 -0000 Martin, You're right, of course, but this attack is easily defeated by the client checking that the server certificate is the same for the outer TLS connection as for the inner one. It's also easily defeated by the server sending a ChangeCipherSpec in the re-negotiation: the MITM will not be able to decrypt or tamper with the record layer for the inner connection (and if the MITM pretends to the client to be the server end of the inner connection then it will not be able to authenticate as the client to the real server). But suppose the MITM can get the client to accept an TLS_DH_anon_* cipher suite for the outer connection: then there's no way for the client to ensure that the server end-points of the two connections are the same. The best way to defeat this now then is to have the server *always* send a ChangeCipherSpec in the re-negotiation. Re-negotiation handshakes are tunneled in the record layer of a previous TLS connection, and the only links between the two connections (inner and outer) are the authentication credentials of the two end-points. Usually the client end-point will be anonymous in the outer connection, and not anonymous in the inner one. And usually the server certificate must be the same in both cases. Checking that the latter is the case and/or sending a ChangeCipherSpec in the re-negotiation, is and should be sufficient; it should also be required. Another solution would be to use bind the outer connection into the inner connection's PRF, so as to ensure that the Finished messages can only check out if both end-points of the inner connection are also the same end-points for the outer connection. This is what we call channel binding. The additional PRF inputs extension would provide the necessary channel binding facility. In general I prefer the channel binding approach because it's easier to make it work in all cases. Anon-anon cipher-suites? No problem. Note that there is a security consideration here for the TLS channel bindings then, particularly tls-unique: if the inner and outer channels are not bound somehow (either by having the same server end-point cert, or by channel binding of the inner to the outer) then we should want the TLS channel binding see by the application to be that of the of the inner channel, _and_ we should want the inner channel's negotiation to have included a ChangeCipherSpec. Thanks for bringing this to light. Nico -- From uri@ll.mit.edu Wed Nov 4 14:48:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506B428C149 for ; Wed, 4 Nov 2009 14:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W63xRrUKeA7c for ; Wed, 4 Nov 2009 14:48:24 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 7C1F33A6A0C for ; Wed, 4 Nov 2009 14:48:24 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nA4Mmgvd009310; Wed, 4 Nov 2009 17:48:42 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAITaWYl; Wed Nov 4 17:42:39 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Wed, 4 Nov 2009 17:42:38 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "Joseph Salowey (jsalowey)" Date: Wed, 4 Nov 2009 17:42:37 -0500 Thread-Topic: [TLS] Interest in taking draft-seggelmann-tls-dtls-heartbeat-01 as a working group item Thread-Index: Acpdl9NgJElUwV+2Q9+kk6c8I0NEiAACEgRD Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] Interest in taking draft-seggelmann-tls-dtls-heartbeat-01 as a working group item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 22:48:25 -0000 I think it is a worthy effort, and approve taking it as a WG item. I may be able to review. Tnx! On 11/4/09 16:43 , "Joseph Salowey (jsalowey)" wrote: > There has been some interest expressed in > draft-seggelmann-tls-dtls-heartbeat. I'd like to see if there is enough > to take this up as a TLS working group item. Please respond if you > approve or disapprove taking this on as a working group item. If you > approve please indicate if you are willing to contribute text or review. >=20 >=20 > Thanks, >=20 > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 Regards, Uri From Nicolas.Williams@sun.com Wed Nov 4 14:58:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5518C3A6A17; Wed, 4 Nov 2009 14:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 fXY3SaVogaXR; Wed, 4 Nov 2009 14:58:50 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 33B2E3A6A2A; Wed, 4 Nov 2009 14:58:49 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4MxBAT018545; Wed, 4 Nov 2009 22:59:11 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 nA4MxBlQ056693; Wed, 4 Nov 2009 15:59:11 -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 nA4MlgLm008697; Wed, 4 Nov 2009 16:47:42 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4MlgDx008696; Wed, 4 Nov 2009 16:47:42 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 16:47:42 -0600 From: Nicolas Williams To: Larry Zhu Message-ID: <20091104224741.GM1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 22:58:51 -0000 On Wed, Nov 04, 2009 at 10:13:46PM +0000, Larry Zhu wrote: > The proposed looks fine. Thanks, Thanks. HOWEVER, Martin's post to the TLS WG list about MITM attacks in re-negotiations is relevant. Re-negotiations have no real binding between inner and outer connections. Clients can enforce that the server end-point is the same (has the same certificate, whatever) for both connections: inner and outer. Servers can also force the inner connection to change cipher specs. But suppose that the outer connection used an TLS_DH_anon_* cipher suite! Then there is no binding whatsoever between the inner and outer connection. And then we have a real problem for tls-unique. We need at least a security considerations note about this. But we should also consider changing tls-unique to be the client's Finished message for the _inner-most_ TLS connection, not outer-most. (Outer-most is OK IFF there's a binding between each channel.) Comments? Nico -- From larry.zhu@microsoft.com Wed Nov 4 16:03:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6CF3A67BD; Wed, 4 Nov 2009 16:03:21 -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 9gnlcYCWjela; Wed, 4 Nov 2009 16:03:21 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 086C73A679F; Wed, 4 Nov 2009 16:03:20 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 16:03:42 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.20; Wed, 4 Nov 2009 16:03:42 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 4 Nov 2009 16:03:43 -0800 From: Larry Zhu To: Nicolas Williams Thread-Topic: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings) Thread-Index: AQHKXaJ3/jMkb6C1dEyRuhhf/zDndZEmmUig Date: Thu, 5 Nov 2009 00:03:41 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <20091104224741.GM1105@Sun.COM> In-Reply-To: <20091104224741.GM1105@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 00:03:22 -0000 I think this is good as is. The mentioned issue is in the TLS itself at whi= ch layer it knows every well what a TLS connection is so we do not have any= confusions related to I mentioned. Now some comments on the alternative proposals, I would prefer a stable ide= ntifier for the channel. If the name of the channel constantly changes when= TLS renegotiates, it is a bad taste in the mouth for me. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicol= as Williams Sent: Wednesday, November 04, 2009 2:48 PM To: Larry Zhu Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindin= gs) On Wed, Nov 04, 2009 at 10:13:46PM +0000, Larry Zhu wrote: > The proposed looks fine. Thanks, Thanks. HOWEVER, Martin's post to the TLS WG list about MITM attacks in re-negotiations is relevant. Re-negotiations have no real binding between inner and outer connections. Clients can enforce that the server end-point is the same (has the same certificate, whatever) for both connections: inner and outer. Servers can also force the inner connection to change cipher specs. But suppose that the outer connection used an TLS_DH_anon_* cipher suite! Then there is no binding whatsoever between the inner and outer connection. And then we have a real problem for tls-unique. We need at least a security considerations note about this. But we should also consider changing tls-unique to be the client's Finished message for the _inner-most_ TLS connection, not outer-most. (Outer-most is OK IFF there's a binding between each channel.) Comments? Nico --=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Wed Nov 4 16:25:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F332528C158; Wed, 4 Nov 2009 16:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 TkA4hARv9z-K; Wed, 4 Nov 2009 16:25:57 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3F2BB28C154; Wed, 4 Nov 2009 16:25:57 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA50QIcB021877; Thu, 5 Nov 2009 00:26: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 nA50QIAw039524; Wed, 4 Nov 2009 17:26: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 nA50EmEv008766; Wed, 4 Nov 2009 18:14:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA50ElEP008765; Wed, 4 Nov 2009 18:14:47 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 18:14:47 -0600 From: Nicolas Williams To: Larry Zhu Message-ID: <20091105001447.GT1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <20091104224741.GM1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] [CHANNEL-BINDING] New Problem (Was: Last Call: draft-altman-tls-channel-bindings) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 00:25:58 -0000 On Thu, Nov 05, 2009 at 12:03:41AM +0000, Larry Zhu wrote: > I think this is good as is. The mentioned issue is in the TLS itself > at which layer it knows every well what a TLS connection is so we do > not have any confusions related to I mentioned. I'm inclined to agree. In fact, changing tls-unique would have zero effect in an HTTPS context if authentication would likely be happening before the server requests a re-negotiation, and if it happens after re-negotiation then it's too late no matter what. Therefore I see that we don't need to change tls-unique at all. > Now some comments on the alternative proposals, I would prefer a > stable identifier for the channel. If the name of the channel > constantly changes when TLS renegotiates, it is a bad taste in the > mouth for me. tls-server-end-point channel bindings are that. tls-unique is a unique type of CB, which means it must be different every time. We can't have any sort of non-unique channel binding for anonymous- anonymous channels. We can have them for anonymous-pseudonymous channels, but we can't create those from where we stand. Nico -- From ekr@rtfm.com Wed Nov 4 19:26:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB05F28C0E9 for ; Wed, 4 Nov 2009 19:26:53 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gbe5sWsrYl8A for ; Wed, 4 Nov 2009 19:26:52 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id D11633A67D7 for ; Wed, 4 Nov 2009 19:26:52 -0800 (PST) Received: by pzk42 with SMTP id 42so6024382pzk.31 for ; Wed, 04 Nov 2009 19:27:12 -0800 (PST) Received: by 10.114.187.20 with SMTP id k20mr1492316waf.213.1257391631794; Wed, 04 Nov 2009 19:27:11 -0800 (PST) Received: from ?10.78.249.58? ([166.205.133.87]) by mx.google.com with ESMTPS id 23sm185479pxi.5.2009.11.04.19.27.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 19:27:11 -0800 (PST) Message-Id: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> From: Eric Rescorla To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=Apple-Mail-4--88454205 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Wed, 4 Nov 2009 19:26:59 -0800 Subject: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 03:26:53 -0000 --Apple-Mail-4--88454205 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit TLS WG members will want to check out this announcement of a new attack on the TLS renegotiation logic. See here: http://www.extendedsubset.com/ The high-level summary is that the attacker negotiates TLS with the server and then subsequently proxies the client's negotiation *over* that channel. This allows the attacker to inject arbitrary content of their choice in front of data sent from the TLS client to the TLS server. This data will be treated by the server as if it came from the client. Once the new handshake has finished, the attacker can't do anything else useful. The attacker doesn't get to directly see any of the client's plaintext messages but could potentially: - Issue commands which would then piggyback on subsequent authentications by the client, including certificate-based authentication. - Potentially get access to data sent by the client by issuing an earlier command which causes the application layer (e.g., HTTP) to send the client's traffic to the server. Marsh Ray, the initial discoverer, has been working with a bunch of people in the security community to deal with this issue and develop a fix. Tomorrow AM I'll be posting an initial draft that describes the obvious fix, which is to cryptographically bind negotiations to any enclosing connection (if any). I won't be in Hiroshima but I expect the WG will want to discuss this topic. -Ekr --Apple-Mail-4--88454205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable TLS WG members will want to check out this = announcement of a
new attack on the TLS renegotiation = logic. See here:

http://www.extendedsubset.com/=

The high-level summary is that the = attacker negotiates TLS with the
server and then = subsequently proxies the client's negotiation = *over*
that channel. This allows the attacker to inject = arbitrary content of
their choice in front of data sent = from the TLS client to the TLS
server. This data will be = treated by the server as if it came from the
client. = Once the new handshake has finished, the attacker = can't 
do anything else = useful.

The attacker doesn't get to = directly see any of the client's plaintext
messages but = could potentially:

- Issue commands = which would then piggyback on subsequent = authentications
 by the client, including = certificate-based authentication.
- Potentially get = access to data sent by the client by = issuing 
 an earlier command which causes the = application layer (e.g., HTTP)
 to send the = client's traffic to the server.

Marsh = Ray, the initial discoverer, has been working with a bunch = of
people in the security community to deal with this = issue and develop
a fix. Tomorrow AM I'll be posting an = initial draft that describes
the obvious fix, which is = to cryptographically bind negotiations
to any enclosing = connection (if any). I won't be in Hiroshima but
I = expect the WG will want to discuss this = topic. 

-Ekr
= --Apple-Mail-4--88454205-- From ekr@rtfm.com Wed Nov 4 19:31:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECC928C0E9 for ; Wed, 4 Nov 2009 19:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zQbCTZggyEK for ; Wed, 4 Nov 2009 19:30:59 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 6E1A328C10E for ; Wed, 4 Nov 2009 19:30:59 -0800 (PST) Received: by pwi4 with SMTP id 4so3856388pwi.29 for ; Wed, 04 Nov 2009 19:31:18 -0800 (PST) Received: by 10.114.50.8 with SMTP id x8mr3744828wax.219.1257391877879; Wed, 04 Nov 2009 19:31:17 -0800 (PST) Received: from ?10.78.249.58? ([166.205.133.87]) by mx.google.com with ESMTPS id 23sm187960pxi.9.2009.11.04.19.31.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 19:31:17 -0800 (PST) References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Message-Id: <054CC553-7D2E-435E-ADE3-4FBE7B2DB3F8@rtfm.com> From: Eric Rescorla To: Eric Rescorla In-Reply-To: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Content-Type: multipart/alternative; boundary=Apple-Mail-5--88206456 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Wed, 4 Nov 2009 19:31:07 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 03:31:00 -0000 --Apple-Mail-5--88206456 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Nov 4, 2009, at 7:26 PM, Eric Rescorla wrote: > TLS WG members will want to check out this announcement of a > new attack on the TLS renegotiation logic. See here: > > http://www.extendedsubset.com/ > > The high-level summary is that the attacker negotiates TLS with the > server and then subsequently proxies the client's negotiation *over* > that channel. This allows the attacker to inject arbitrary content of > their choice in front of data sent from the TLS client to the TLS > server. This data will be treated by the server as if it came from the > client. Once the new handshake has finished, the attacker can't > do anything else useful. > > The attacker doesn't get to directly see any of the client's plaintext > messages but could potentially: > > - Issue commands which would then piggyback on subsequent > authentications > by the client, including certificate-based authentication. > - Potentially get access to data sent by the client by issuing > an earlier command which causes the application layer (e.g., HTTP) > to send the client's traffic to the server. > > Marsh Ray, the initial discoverer, has been working with a bunch of > people in the security community to deal with this issue and develop > a fix. I should also mention his colleague from phonefactor, steve dispensa. Ekr > Tomorrow AM I'll be posting an initial draft that describes > the obvious fix, which is to cryptographically bind negotiations > to any enclosing connection (if any). I won't be in Hiroshima but > I expect the WG will want to discuss this topic. > > -Ekr --Apple-Mail-5--88206456 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Nov 4, 2009, at 7:26 PM, = Eric Rescorla <ekr@rtfm.com> = wrote:

http://www.extendedsubset.com/=

The high-level summary is that the = attacker negotiates TLS with the
server and then = subsequently proxies the client's negotiation = *over*
that channel. This allows the attacker to inject = arbitrary content of
their choice in front of data sent = from the TLS client to the TLS
server. This data will be = treated by the server as if it came from the
client. = Once the new handshake has finished, the attacker = can't 
do anything else = useful.

The attacker doesn't get to = directly see any of the client's plaintext
messages but = could potentially:

- Issue commands = which would then piggyback on subsequent = authentications
 by the client, including = certificate-based authentication.
- Potentially get = access to data sent by the client by = issuing 
 an earlier command which causes the = application layer (e.g., HTTP)
 to send the = client's traffic to the server.

Marsh = Ray, the initial discoverer, has been working with a bunch = of
people in the security community to deal with this = issue and develop
a fix. =

I should also mention = his colleague from phonefactor, steve = dispensa. 

Ekr
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <054CC553-7D2E-435E-ADE3-4FBE7B2DB3F8@rtfm.com> In-Reply-To: <054CC553-7D2E-435E-ADE3-4FBE7B2DB3F8@rtfm.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 03:40:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just out: http://extendedsubset.com/?p=8 Eric Rescorla wrote: > > I should also mention his colleague from phonefactor, steve dispensa. And I should mention that EKR, as well as some others who frequent this group, have been invaluable in this process so far. I should mention it, but I didn't because I've deliberately left out names where I didn't have a chance to touch base with the person first. Anyway, I hope this info proves to be valuable and timely for the Hiroshima meeting. By the way, I'm available if I can help answer questions on this list, on the phone, or direct email marsh@extendedsubset.com . - - Marsh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrySUAACgkQWChJ3x422/KR/gCfcoAZMgD4RsXVUtLinCSDYWnk 14YAnAmtQWE64+61Z0y5ioh/NM1DoPyz =YVva -----END PGP SIGNATURE----- From ekr@rtfm.com Wed Nov 4 19:41:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6155728C18D for ; Wed, 4 Nov 2009 19:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiedDVRtEC8o for ; Wed, 4 Nov 2009 19:41:04 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 81DBC28C189 for ; Wed, 4 Nov 2009 19:41:04 -0800 (PST) Received: by pwi4 with SMTP id 4so3860939pwi.29 for ; Wed, 04 Nov 2009 19:41:24 -0800 (PST) Received: by 10.115.102.38 with SMTP id e38mr3780047wam.207.1257392480220; Wed, 04 Nov 2009 19:41:20 -0800 (PST) Received: from ?10.78.249.58? ([166.205.133.87]) by mx.google.com with ESMTPS id 22sm966312pxi.2.2009.11.04.19.41.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 19:41:19 -0800 (PST) References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <054CC553-7D2E-435E-ADE3-4FBE7B2DB3F8@rtfm.com> Message-Id: <11BF701F-5158-4B9B-A951-B25FEC84A68B@rtfm.com> From: Eric Rescorla To: Eric Rescorla In-Reply-To: <054CC553-7D2E-435E-ADE3-4FBE7B2DB3F8@rtfm.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6--87604893 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Wed, 4 Nov 2009 19:41:08 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 03:41:05 -0000 --Apple-Mail-6--87604893 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Oh I should or course also mention that this is substantively similar to the issue Martin recently raised Ekr On Nov 4, 2009, at 7:31 PM, Eric Rescorla wrote: > > > On Nov 4, 2009, at 7:26 PM, Eric Rescorla wrote: > >> TLS WG members will want to check out this announcement of a >> new attack on the TLS renegotiation logic. See here: >> >> http://www.extendedsubset.com/ >> >> The high-level summary is that the attacker negotiates TLS with the >> server and then subsequently proxies the client's negotiation *over* >> that channel. This allows the attacker to inject arbitrary content of >> their choice in front of data sent from the TLS client to the TLS >> server. This data will be treated by the server as if it came from >> the >> client. Once the new handshake has finished, the attacker can't >> do anything else useful. >> >> The attacker doesn't get to directly see any of the client's >> plaintext >> messages but could potentially: >> >> - Issue commands which would then piggyback on subsequent >> authentications >> by the client, including certificate-based authentication. >> - Potentially get access to data sent by the client by issuing >> an earlier command which causes the application layer (e.g., HTTP) >> to send the client's traffic to the server. >> >> Marsh Ray, the initial discoverer, has been working with a bunch of >> people in the security community to deal with this issue and develop >> a fix. > > I should also mention his colleague from phonefactor, steve dispensa. > > Ekr >> Tomorrow AM I'll be posting an initial draft that describes >> the obvious fix, which is to cryptographically bind negotiations >> to any enclosing connection (if any). I won't be in Hiroshima but >> I expect the WG will want to discuss this topic. >> >> -Ekr --Apple-Mail-6--87604893 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Oh I should or course also mention = that this is substantively similar to the issue Martin recently = raised

Ekr

On Nov 4, 2009, at 7:31 PM, = Eric Rescorla <ekr@rtfm.com> = wrote:



On Nov 4, 2009, at 7:26 PM, Eric = Rescorla <ekr@rtfm.com> = wrote:

http://www.extendedsubset.com/=

The high-level summary is that the = attacker negotiates TLS with the
server and then = subsequently proxies the client's negotiation = *over*
that channel. This allows the attacker to inject = arbitrary content of
their choice in front of data sent = from the TLS client to the TLS
server. This data will be = treated by the server as if it came from the
client. = Once the new handshake has finished, the attacker = can't 
do anything else = useful.

The attacker doesn't get to = directly see any of the client's plaintext
messages but = could potentially:

- Issue commands = which would then piggyback on subsequent = authentications
 by the client, including = certificate-based authentication.
- Potentially get = access to data sent by the client by = issuing 
 an earlier command which causes the = application layer (e.g., HTTP)
 to send the = client's traffic to the server.

Marsh = Ray, the initial discoverer, has been working with a bunch = of
people in the security community to deal with this = issue and develop
a fix. =

I should also mention = his colleague from phonefactor, steve = dispensa. 

Ekr
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:26:01 -0000 Can someone comment on the similarities and differences of TLS channel binding and TLS keying material exporters? Is the keying material derived from a TLS master key using a keying material exporter suitable for channel binding as well, if used for key confirmation? If a higher-level application wishes to do additional authentication and bind the endpoints of that authentication to the endpoints of the TLS connection, should one use key confirmation with keying material exporters or something from TLS channel binding? Thanks, Douglas From Nicolas.Williams@sun.com Thu Nov 5 09:10:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D1F3A6768 for ; Thu, 5 Nov 2009 09:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 b-D4t7wxc6fI for ; Thu, 5 Nov 2009 09:10:24 -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 DD9623A67EA for ; Thu, 5 Nov 2009 09:10:21 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA5HAW6G008548 for ; Thu, 5 Nov 2009 17:10:44 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 nA5HAWA2040295 for ; Thu, 5 Nov 2009 10:10:32 -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 nA5Gx1bU009151; Thu, 5 Nov 2009 10:59:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5Gx1bM009150; Thu, 5 Nov 2009 10:59:01 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 10:59:00 -0600 From: Nicolas Williams To: Douglas Stebila Message-ID: <20091105165900.GW1105@Sun.COM> References: <3DE8D6FD-CABD-4851-9ACC-189CB0E1CE61@stebila.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DE8D6FD-CABD-4851-9ACC-189CB0E1CE61@stebila.ca> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Channel binding versus keying material exporters X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:10:25 -0000 On Fri, Nov 06, 2009 at 12:23:05AM +0800, Douglas Stebila wrote: > Can someone comment on the similarities and differences of TLS channel > binding and TLS keying material exporters? Is the keying material > derived from a TLS master key using a keying material exporter > suitable for channel binding as well, if used for key confirmation? > If a higher-level application wishes to do additional authentication > and bind the endpoints of that authentication to the endpoints of the > TLS connection, should one use key confirmation with keying material > exporters or something from TLS channel binding? TLS connections[0] form a secure channel. They also optionally provide authentication, and are often run on top of other TLS connections[1]. Therefore there's two ways in which channel binding is interesting for TLS: a) you should be able to get channel binding information _from_ a TLS channel to bind into authentication at a higher layer, b) you should be able to provide channel binding information to TLS to bind into its handshake. The two ways in which TLS relates to channel binding are two sides of the same coin, but we need to look at them separately. At this point I recommend reading RFC5056. For (a), see draft-altman-tls-channel-bindings-07. For (b), see the recent draft-solinas-tls-additional-prf-input-00. You ask if we could use the TLS exporter to create a channel binding for TLS, and the answer is: no, or at least not by itself. You could use the exporter to construct a channel binding that is sufficiently secure, but why re-invent the wheel? You really should use one of the channel binding types for TLS defined in draft-altman-tls-channel-bindings-07. The TLS exporter, as defined in draft-ietf-tls-extractor-07, is this: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[length] Compare that to the Finished message computation: PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; Both use the TLS PRF() and master secret. But only the second formulation also binds all the handshake messages. The second formulation therefore protects all of the negotiation involved in a TLS exchange, while the first protects only the key exchange, and that makes the Finished message construction more appropriate as a channel binding for TLS than the exporter. This has been much, much discussed in the past in the context of draft-altman-tls-channel-bindings, including one or more proposals that we use the TLS PRF instead of Finished messages. That we need to use a Finished message or a similar construction is and has been the consensus for a long time. [0] There's been a lot of confusion lately about what is meant when one says "TLS connection". I use it to mean "the TLS state created by a TLS hello, handshake and finished message exchange". [1] This is called re-negotiation. The client initiates one TLS exchange, then either the client or server initiates a second exchange. This is basically TLS-over-TLS, though to be pedantic, the inner connection can replace the outer, so it's not quite TLS-over-TLS, but the inner TLS connection's handshake does happen with the protection of the outer TLS connection's record layer. As you surely know by now, there's no real binding between the inner and outer TLS connections -- the only possible binding is for the client to enforce that the server uses a cert in both TLS connections, and that it uses the _same_ cert in both TLS connections. From EKR's message about the re-negotiation MITM vulnerability, I gather that TLS will be modified to provide a direct channel binding that both, the client _and_ server can enforce for the nested TLS case. IMO that's the correct solution, though in the very short-term the quickest, most interoperable solution is for clients to do as described in above. Nico -- From mrex@sap.com Thu Nov 5 09:11:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CAEB3A6952 for ; Thu, 5 Nov 2009 09:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 hSCjdaKH-yyD for ; Thu, 5 Nov 2009 09:11:22 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D03053A694F for ; Thu, 5 Nov 2009 09:11:21 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5HBg9d024137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 18:11:42 +0100 (MET) From: Martin Rex Message-Id: <200911051711.nA5HBfOl028765@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 5 Nov 2009 18:11:41 +0100 (MET) In-Reply-To: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> from "Eric Rescorla" at Nov 4, 9 07:26:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:11:23 -0000 Eric Rescorla wrote: > > Marsh Ray, the initial discoverer, has been working with a bunch of > people in the security community to deal with this issue and develop > a fix. Tomorrow AM I'll be posting an initial draft that describes > the obvious fix, which is to cryptographically bind negotiations > to any enclosing connection (if any). I won't be in Hiroshima but > I expect the WG will want to discuss this topic. One conceivable approach would be a TLS extension for secure renegotiation with roughly the following semantics: - on initial TLS handshakes (aka Re-nego of a TLS_NULL_WITH_NULL_NULL) the client that supports secure renegotiation should send the TLS extension in the client hello with an empty extension data to signal to the server that it support secure renegotation. - on TLS session renegotiations, the client should sent the TLS extension with the extension data containing the client.random and server.random from the existing session. - A server that receives a ClientHello without the TLS extension for secure renegotiation should NOT perform old-style renegotiation for that session (and get apps with flawed assumptions into trouble), i.e. NOT support delayed authentication for those TLS clients. - A server that receives a ClientHello on an initial TLS handshake with a TLS extension (empty data) for secure renegotiation may decide to delay client-cert authentication to a securely renegotiated session - A server that receives a ClientHello with a TLS extension for secure negotiation and a reference to a previous session MUST compare the client.random and server.random from the extension data to that of the current session (and abort if they do not match). And the server should probably insist on doing a ChangeCipherSpec on both directions in the renegotiation handshake. Since Larry is looking for a means to uniquely identify a single TLS "connection" independent of whether its a single TLS handshake or renegotiated, we should check whether we can carry-over some information form the initial handshake on a connection along with the client.random&server.random. Technically there is no limit on the number of renegotiations, so a simple pointer only one TLS session into the past does not seem sufficient for that purpose. -Martin From marsh@extendedsubset.com Thu Nov 5 09:23:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF9A3A6AFB for ; Thu, 5 Nov 2009 09:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.666, 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 bkMsF6JP1g0H for ; Thu, 5 Nov 2009 09:23:06 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id EF7EF3A69AC for ; Thu, 5 Nov 2009 09:23:05 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N663U-000AQg-7N; Thu, 05 Nov 2009 17:23:28 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 78C016678; Thu, 5 Nov 2009 17:23:26 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18OCiF2fHVrGbm305r3L0gwak6nTxZdxOI= Message-ID: <4AF30A0E.5030409@extendedsubset.com> Date: Thu, 05 Nov 2009 11:23:26 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com, "tls@ietf.org" References: <200911051711.nA5HBfOl028765@fs4113.wdf.sap.corp> In-Reply-To: <200911051711.nA5HBfOl028765@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:23:06 -0000 I expect that EKR will be posting some details soon. Martin Rex wrote: > > Technically there is no > limit on the number of renegotiations, so a simple pointer > only one TLS session into the past does not seem sufficient > for that purpose. I agree, the concept of "first handshake on the socket" is a bit nebulous from the perspective of the TLS spec. The approach our proposal took was to work off of the "most recent previous finished message" over the underlying transport. - Marsh From Nicolas.Williams@sun.com Thu Nov 5 09:24:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA58C3A6AEA for ; Thu, 5 Nov 2009 09:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.245 X-Spam-Level: X-Spam-Status: No, score=-5.245 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_BACKHAIR_46=1, J_CHICKENPOX_66=0.6, 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 jhN9cNfCp0BD for ; Thu, 5 Nov 2009 09:24:41 -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 CB1253A67D9 for ; Thu, 5 Nov 2009 09:24:16 -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 nA5HOdP2028895 for ; Thu, 5 Nov 2009 17:24:39 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 nA5HOdPW051900 for ; Thu, 5 Nov 2009 10:24:39 -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 nA5HD8Rl009208; Thu, 5 Nov 2009 11:13:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5HD8nP009207; Thu, 5 Nov 2009 11:13:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 11:13:08 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105171308.GY1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <200911051711.nA5HBfOl028765@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911051711.nA5HBfOl028765@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:24:42 -0000 On Thu, Nov 05, 2009 at 06:11:41PM +0100, Martin Rex wrote: > One conceivable approach would be a TLS extension for secure renegotiation > with roughly the following semantics: > > > - on initial TLS handshakes (aka Re-nego of a TLS_NULL_WITH_NULL_NULL) > the client that supports secure renegotiation should send the > TLS extension in the client hello with an empty extension data > to signal to the server that it support secure renegotation. > > - on TLS session renegotiations, the client should sent the TLS extension > with the extension data containing the client.random and server.random > from the existing session. The MITM can make sure they match. Why not just send an extension with the tls-unique channel binding for the first/outer connection, and then make sure that that gets fed as an input for the PRF in the second/inner connection? I.e., proper channel binding. The MITM _cannot_ make sure that the tls-unique CB of the client<->MITM and MITM<->server outer connections match. > - A server that receives a ClientHello without the TLS extension for > secure renegotiation should NOT perform old-style renegotiation > for that session (and get apps with flawed assumptions into trouble), > i.e. NOT support delayed authentication for those TLS clients. Right. > - A server that receives a ClientHello on an initial TLS handshake > with a TLS extension (empty data) for secure renegotiation may decide to > delay client-cert authentication to a securely renegotiated session Right. > - A server that receives a ClientHello with a TLS extension for secure > negotiation and a reference to a previous session MUST compare the > client.random and server.random from the extension data to that of > the current session (and abort if they do not match). And the > server should probably insist on doing a ChangeCipherSpec on both > directions in the renegotiation handshake. See above. > Since Larry is looking for a means to uniquely identify a single > TLS "connection" independent of whether its a single TLS handshake > or renegotiated, we should check whether we can carry-over some > information form the initial handshake on a connection along > with the client.random&server.random. Technically there is no > limit on the number of renegotiations, so a simple pointer > only one TLS session into the past does not seem sufficient > for that purpose. See above. Use tls-unique. Nico -- From mrex@sap.com Thu Nov 5 09:37:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D0C3A6B45 for ; Thu, 5 Nov 2009 09:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 at5MsgGV83XM for ; Thu, 5 Nov 2009 09:37:52 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DE9453A6B42 for ; Thu, 5 Nov 2009 09:37:51 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5HcBhn022932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 18:38:11 +0100 (MET) From: Martin Rex Message-Id: <200911051738.nA5HcA4Y000486@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 5 Nov 2009 18:38:10 +0100 (MET) In-Reply-To: <4AF30A0E.5030409@extendedsubset.com> from "Marsh Ray" at Nov 5, 9 11:23:26 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:37:53 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > > > Technically there is no > > limit on the number of renegotiations, so a simple pointer > > only one TLS session into the past does not seem sufficient > > for that purpose. > > I agree, the concept of "first handshake on the socket" is a bit > nebulous from the perspective of the TLS spec. For the secure renegotiation, the pointer exactly one TLS session into the past seems perfectly sufficient to me. Solving the nebulous concept of "first handshake on the socket" is something that Larry wants a solution for, and which needs a different approach. The "secure naming" of a TLS connection has much more to do with API semantics than with TLS wire-protocol and TLS session state. TLS renegotiation does IMHO also interfere with the TLS PRF (aka TLS-extractors), so that applications can not call it at arbitrary points in their communication with a peer when there might be a renegotiation between the point in time when the client app calls in and when the server app calls it. > > The approach our proposal took was to work off of the "most recent > previous finished message" over the underlying transport. The "secure random challenges" in a TLS handshake that protect agains replay are the client.random and server.random. Admittedly they're larger (2*32 octets, fixed size) than the finished message (usually 12 octets, but depends on ciphersuite according to rfc5246 7.4.9.) The client.random and server.random of a connection are already part of the official SecurityParameters (rfc5246 6.1.), but the finished message is not. -Martin From Nicolas.Williams@sun.com Thu Nov 5 09:43:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC67D3A6B45 for ; Thu, 5 Nov 2009 09:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=0.013, 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 SebyMH58IUpB for ; Thu, 5 Nov 2009 09:43:53 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id DD81C3A696F for ; Thu, 5 Nov 2009 09:43:52 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5HiEEt005529 for ; Thu, 5 Nov 2009 17:44:14 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 nA5HiEkC002392 for ; Thu, 5 Nov 2009 10:44:14 -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 nA5HPECO009228; Thu, 5 Nov 2009 11:25:14 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5HPEJO009227; Thu, 5 Nov 2009 11:25:14 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 11:25:14 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091105172514.GA1105@Sun.COM> References: <200911051711.nA5HBfOl028765@fs4113.wdf.sap.corp> <4AF30A0E.5030409@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF30A0E.5030409@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:43:53 -0000 On Thu, Nov 05, 2009 at 11:23:26AM -0600, Marsh Ray wrote: > I expect that EKR will be posting some details soon. We await with bated breath :) > Martin Rex wrote: > > > > Technically there is no > > limit on the number of renegotiations, so a simple pointer > > only one TLS session into the past does not seem sufficient > > for that purpose. > > I agree, the concept of "first handshake on the socket" is a bit > nebulous from the perspective of the TLS spec. Only at first glance. The "first handshake", or, rather, "outer-most handshake" is really one that occurs with null cipher spec, that is, not under the protection of another TLS connection. > The approach our proposal took was to work off of the "most recent > previous finished message" over the underlying transport. I recommend "the client finished, in cleartext, from the outer-most handshake", with "first handshake" as described above. Better yet, though equivalently, I recommend "the tls-unique channel bindings of the outer-most handshake". (Or at least state the equivalence, and add a reference to draft-altman-tls-channel-bindings and RFC5056.) Nico -- From mrex@sap.com Thu Nov 5 09:45:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5889C3A696F for ; Thu, 5 Nov 2009 09:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 8uWojBkluH6F for ; Thu, 5 Nov 2009 09:45:25 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4BEF93A6869 for ; Thu, 5 Nov 2009 09:45:25 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5Hjkvr000868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 18:45:46 +0100 (MET) From: Martin Rex Message-Id: <200911051745.nA5Hjke7001138@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 5 Nov 2009 18:45:46 +0100 (MET) In-Reply-To: <20091105171308.GY1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 11:13:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:45:26 -0000 Nicolas Williams wrote: > > On Thu, Nov 05, 2009 at 06:11:41PM +0100, Martin Rex wrote: > > One conceivable approach would be a TLS extension for secure renegotiation > > with roughly the following semantics: > > > > > > - on initial TLS handshakes (aka Re-nego of a TLS_NULL_WITH_NULL_NULL) > > the client that supports secure renegotiation should send the > > TLS extension in the client hello with an empty extension data > > to signal to the server that it support secure renegotation. > > > > - on TLS session renegotiations, the client should sent the TLS extension > > with the extension data containing the client.random and server.random > > from the existing session. > > The MITM can make sure they match. Not a problem. If it does, that will become obvious in the verification of the finished messages of the renegotiation handshake. In addition to the Finished Message verification, such doctoring will be detected in the ClientVerify verification by the server when that is a signature over all previous handshake messages (which is the default). I'm usually prefer low-impact improvements, which can be added to existing codebase with ease. client.random | server.random from the existing connection seems like a good candidate to me. -Martin From Nicolas.Williams@sun.com Thu Nov 5 09:56:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8413A6B45 for ; Thu, 5 Nov 2009 09:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.733 X-Spam-Level: X-Spam-Status: No, score=-5.733 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_66=0.6, 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 4m0I1rohTG+Q for ; Thu, 5 Nov 2009 09:56:08 -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 7F6413A683D for ; Thu, 5 Nov 2009 09:56:08 -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 nA5HuVm9007945 for ; Thu, 5 Nov 2009 17:56:31 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 nA5HuUdh011228 for ; Thu, 5 Nov 2009 10:56:31 -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 nA5HbVw2009256; Thu, 5 Nov 2009 11:37:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5HbVbk009255; Thu, 5 Nov 2009 11:37:31 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 11:37:31 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105173730.GC1105@Sun.COM> References: <4AF30A0E.5030409@extendedsubset.com> <200911051738.nA5HcA4Y000486@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911051738.nA5HcA4Y000486@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:56:09 -0000 On Thu, Nov 05, 2009 at 06:38:10PM +0100, Martin Rex wrote: > The "secure random challenges" in a TLS handshake that protect > agains replay are the client.random and server.random. > Admittedly they're larger (2*32 octets, fixed size) than the > finished message (usually 12 octets, but depends on ciphersuite > according to rfc5246 7.4.9.) > > The client.random and server.random of a connection are already > part of the official SecurityParameters (rfc5246 6.1.), but > the finished message is not. Guess what: the finished messages will have to become something that TLS implementations export to applications. There's no two ways about it folks. Nico -- From Nicolas.Williams@sun.com Thu Nov 5 10:01:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE5428C113 for ; Thu, 5 Nov 2009 10:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_BACKHAIR_46=1, J_CHICKENPOX_66=0.6, 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 y6cXsJO0RifD for ; Thu, 5 Nov 2009 10:01:52 -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 958C628C116 for ; Thu, 5 Nov 2009 10:01:52 -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 nA5I2FMs009785 for ; Thu, 5 Nov 2009 18:02:15 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 nA5I2EiJ016395 for ; Thu, 5 Nov 2009 11:02:15 -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 nA5Hoixl009265; Thu, 5 Nov 2009 11:50:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5HoiH6009264; Thu, 5 Nov 2009 11:50:44 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 11:50:44 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105175044.GG5124@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <200911051711.nA5HBfOl028765@fs4113.wdf.sap.corp> <20091105171308.GY1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091105171308.GY1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:01:53 -0000 On Thu, Nov 05, 2009 at 11:13:08AM -0600, Nicolas Williams wrote: > On Thu, Nov 05, 2009 at 06:11:41PM +0100, Martin Rex wrote: > > - on TLS session renegotiations, the client should sent the TLS extension > > with the extension data containing the client.random and server.random > > from the existing session. > > The MITM can make sure they match. > > Why not just send an extension with the tls-unique channel binding for > the first/outer connection, and then make sure that that gets fed as an > input for the PRF in the second/inner connection? I.e., proper channel > binding. The MITM _cannot_ make sure that the tls-unique CB of the > client<->MITM and MITM<->server outer connections match. I should expand on this. Suppose you have: client <-> MITM <-> server When the client sends its outer conenction client Hello to the MITM, the MITM sends one with the same client.random to the server and waits for the server to send its Hello back, then the MITM sends a Hello back to the client using the same server.random that the server sent to the MITM. The first exchange completes on both sides of the MITM, then the client sends a request. The MITM replaces the client's request with whatever the MITM wants and sends that to the server. The server requests a re-negotiation, the MITM passes that on. When the client and server re-negotiate they will see that the client.random and server.random from the outer TLS connection matches. The MITM wins. You can't use the client.random and server.random as channel bindings. But the client's Finished message from the outer TLS connection works. Suppose the first handshake uses an anonymous DH cipher suite. The MITM cannot solve the discrete logarithm problem, therefore the MITM cannot make sure that the client and server exponentials match for both, the client<->MITM and MITM<->server connections, therefore the MITM also cannot cause the Finished messages to match. Suppose the first handshake uses an RSA key transport key exchange. This means there must be a server cert. The MITM cannot make sure that the server cert seen by the client in its client<->MITM TLS connection matches that of the real server in the MITM<->server TLS connection without either possessing the server's private key or breaking RSA. In all cases, no matter what the TLS key exchange method used, the Finished messages had better bind the entire handshake and the key exchange in such a way that no MITM can force the Finished messages to have any particular value or otherwise match another connection's Finished messages. This is central to the security of TLS. If a MITM can make the Finished messages for two connections match, then the MITM must have broken TLS itself. That's what makes the TLS Finished messages such a wonderful channel binding for TLS connections. (In all cases, if the MITM can solve the discrete logarithm problem, has possession of the server's private key, or can break RSA, you have bigger problems than a MITM attack.) Nico -- From mrex@sap.com Thu Nov 5 10:15:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B1628C223 for ; Thu, 5 Nov 2009 10:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 h+W8L4zFkES2 for ; Thu, 5 Nov 2009 10:15:42 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 0B98E28C220 for ; Thu, 5 Nov 2009 10:15:41 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5IG3JD002494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 19:16:03 +0100 (MET) From: Martin Rex Message-Id: <200911051816.nA5IG292002997@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 5 Nov 2009 19:16:02 +0100 (MET) In-Reply-To: <20091105175044.GG5124@Sun.COM> from "Nicolas Williams" at Nov 5, 9 11:50:44 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:15:43 -0000 Nicolas Williams wrote: > > > The MITM can make sure they match. > > I should expand on this. > [helpful explanantion removed] Blush -- you are correct. The MITM can make the two previous sessions come out with the same client.random and server.random. So these are not a secure back pointer. > > You can't use the client.random and server.random as channel bindings. I'm trying to use terminology that is already in the TLS specs. The generic term "channel bindings" is a little bit to fuzzy for my taste, and the original use of channel bindings in GSS-API is not cryptographically secure. > > But the client's Finished message from the outer TLS connection works. OK. You win. ;-) -Martin From ekr@rtfm.com Thu Nov 5 10:16:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DF828C225 for ; Thu, 5 Nov 2009 10:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 TI5r8mLFp+oh for ; Thu, 5 Nov 2009 10:16:01 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 6786828C0E1 for ; Thu, 5 Nov 2009 10:16:01 -0800 (PST) Received: by yxe30 with SMTP id 30so262640yxe.29 for ; Thu, 05 Nov 2009 10:16:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.54.8 with SMTP id g8mr6911611agk.83.1257444971188; Thu, 05 Nov 2009 10:16:11 -0800 (PST) In-Reply-To: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Date: Thu, 5 Nov 2009 10:16:11 -0800 Message-ID: From: Eric Rescorla To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:16:02 -0000 I now have a draft extension up at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml Comments welcome. -Ekr From Nicolas.Williams@sun.com Thu Nov 5 10:37:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084983A6B40 for ; Thu, 5 Nov 2009 10:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_66=0.6, 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 n7A9X4ysV4UM for ; Thu, 5 Nov 2009 10:37:34 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 2FB053A68E0 for ; Thu, 5 Nov 2009 10:37:34 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5Ibuxr027787 for ; Thu, 5 Nov 2009 18:37:56 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 nA5Ibu2P065507 for ; Thu, 5 Nov 2009 11:37:56 -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 nA5IQQKx009291; Thu, 5 Nov 2009 12:26:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5IQQ9B009290; Thu, 5 Nov 2009 12:26:26 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 12:26:26 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105182625.GE1105@Sun.COM> References: <20091105175044.GG5124@Sun.COM> <200911051816.nA5IG292002997@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911051816.nA5IG292002997@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:37:35 -0000 On Thu, Nov 05, 2009 at 07:16:02PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > You can't use the client.random and server.random as channel bindings. > > I'm trying to use terminology that is already in the TLS specs. > The generic term "channel bindings" is a little bit to fuzzy for > my taste, and the original use of channel bindings in GSS-API > is not cryptographically secure. I understand. The spec will just have to be updated to say that the finished messages (or at least the client one) are to be exported to applications. TLS implementors, know this: you must update your implementations to export to applications, at least the client Finished message for at least any and all "outer-most" TLS handshakes (that is, handshakes not protected by another TLS connection's record layer). This is just a matter of interfaces for all software implementations. For hardware implementations it's going to be tougher -- particularly tough for concentrator implementations. (Provided that a concentrator terminates both, the outer and inner TLS connections, then all other uses of TLS channel binding can use the tls-server-end-point channel binding type. But really, you'll want to export the tls-unique channel bindings.) > > But the client's Finished message from the outer TLS connection works. > > OK. > > You win. ;-) Hey, it's not about winning! I perfectly understand, and _share_, the desire to use existing interfaces where possible. In this case there is no such interface (in some TLS APIs apps could parse the TLS record layer and heuristically find the record that contains the protected client Finished message, but that's... not really an interface, not what we wnat, and not reliably available everywhere). We've looked at this problem many times before, and this is always the conclusion that we've come to. I really wish that TLS 1.2 had made the client Finished messages part of the exported security parameters (I really wish I'd thought to make sure that 1.2 did that). But then, making the 1.2 spec say this is not enough: installed base inertia is what makes it hard to ensure that Finished messages are exported. Nico -- From Nicolas.Williams@sun.com Thu Nov 5 10:40:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7933A6B40 for ; Thu, 5 Nov 2009 10:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.032, 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 7Zt9zd9dqYiY for ; Thu, 5 Nov 2009 10:40:01 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id EACF73A680B for ; Thu, 5 Nov 2009 10:40:00 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5IeNhg028828 for ; Thu, 5 Nov 2009 18:40: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 nA5IeNXg001764 for ; Thu, 5 Nov 2009 11:40: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 nA5ISrZa009299; Thu, 5 Nov 2009 12:28:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5ISrvC009298; Thu, 5 Nov 2009 12:28:53 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 12:28:53 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105182853.GF1105@Sun.COM> References: <20091105175044.GG5124@Sun.COM> <200911051816.nA5IG292002997@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911051816.nA5IG292002997@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:40:01 -0000 On Thu, Nov 05, 2009 at 07:16:02PM +0100, Martin Rex wrote: > I'm trying to use terminology that is already in the TLS specs. > The generic term "channel bindings" is a little bit to fuzzy for > my taste, and the original use of channel bindings in GSS-API > is not cryptographically secure. Also, the term "channel bindings" is only fuzzy as used in RFCs 2743/2744. But RFC5056 put an end to that. If you believe that RFC5056 leaves the term too fuzzy still, then please explain how, and then we can look at updating RFC5056 if need be. Nico -- From fweimer@bfk.de Thu Nov 5 10:40:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0EC28C110 for ; Thu, 5 Nov 2009 10:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XtItV+RDbe3 for ; Thu, 5 Nov 2009 10:40:01 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 90A533A69F0 for ; Thu, 5 Nov 2009 10:40:01 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1N67Ft-0006lZ-KC; Thu, 05 Nov 2009 19:40:21 +0100 Received: by bfk.de with local id 1N67Ft-0002CR-Gw; Thu, 05 Nov 2009 18:40:21 +0000 To: Eric Rescorla References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> From: Florian Weimer Date: Thu, 05 Nov 2009 18:40:21 +0000 In-Reply-To: (Eric Rescorla's message of "Thu\, 5 Nov 2009 10\:16\:11 -0800") Message-ID: <82aaz0rf1m.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:40:02 -0000 * Eric Rescorla: > I now have a draft extension up at: > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renego= tiate.txt > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renego= tiate.xml > > Comments welcome. Most email addresses are incorrect. 8-) Based on the attack description in the draft, the server can implement a layering violation and detect a splicing which crosses an application-layer record boundary (which should result in a hard error). If the splicing does not cross a boundary, there is not really any ambiguity, just a succession of differently authenticated application records. What seems to happen in vulnerable applications I've created in a previous life (but I have no longer access to them, so I can't check for sure) is that in a HTTP context, you tend to perform a sub-request within the server to get the authentication information which only applies to future requests, and use that to answer the not-really-authenticated request as if it were authenticated. As a result, you're still vulnerable even if you refuse to renegotiation in the middle of an HTTP request message. So avoiding protocol changes seems to require an API change (to expose part of the TLS record layer to the application layer, so that byte-exact authentication information is available) plus extensive application code changes, potentially resulting in additional client/server round-trips. Therefore, I think a protocol change is less invasive (assuming that it is essentially free-for-all-uses IPR-wise). --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mrex@sap.com Thu Nov 5 10:48:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F5128C0E3 for ; Thu, 5 Nov 2009 10:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 DPHnElOZgoL0 for ; Thu, 5 Nov 2009 10:48:05 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 434103A63EB for ; Thu, 5 Nov 2009 10:48:05 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5ImQY2021184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 19:48:26 +0100 (MET) From: Martin Rex Message-Id: <200911051848.nA5ImQaY004909@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 5 Nov 2009 19:48:26 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Nov 5, 9 10:16:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:48:06 -0000 Eric Rescorla wrote: > > I now have a draft extension up Thanks Eric. Page 5: The contents of this extension are specified as follows. [...] The above rules apply even when TLS resumption is used. I read this as meaning that the client and server should add two elements client.verify_data and server.verify_data to their SecurityParameters for the connection state suggested by RFC5246 6.1. and update this data on EVERY TLS handshake, even TLS session resume. 4.1 Client Considerations I can understand what it says, but I _really_ dislike it. The root of the problem is servers that perform (or at least allow) TLS renegotiations and make flawed assumptions about what a successful TLS renegotiation means for the data previously received. What you're essentially asking for, is that a client should no longer talk TLS to _any_ Server that doesn't support the new extension. Not even to the good ones that neither offer nor support renegotiation. This is discriminating against servers that have been playing safe! Essentially we are going to hold TLS clients and the installed base of good Servers responsible for the broken Servers out there. That feels very wrong. -Martin PS: > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt That URL results in a cert warning in my Firefox browser. Following the Client considerations, I feel much safer removing the "s" in "https" in the URL than trying to add an exception for the servers certificate... ;-) From mike-list@pobox.com Thu Nov 5 10:49:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CDAC3A68E0 for ; Thu, 5 Nov 2009 10:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 uIvT+QH2rVtn for ; Thu, 5 Nov 2009 10:49:27 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 14D8C3A63EB for ; Thu, 5 Nov 2009 10:49:26 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 361677525F; Thu, 5 Nov 2009 13:49:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Q3IZ0M3oM+R2 gncw8iXz3UPIo+4=; b=In9oLdQ7tyglRUsmB3MGjui3DBhK3bODuFk0vCALPj1B x9zButpgaArniNPgJgGs/LHK7gYx+F+ZXafOa2DMuPQA6Hel6IonUawn/K1Z1h2h +uottO+nMiNpr5e91sxcscT/oIjePQHnXZzrKuYmKJXUQRqkjpRh05YFf6kb/Og= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=FvBbCn ZiDRf6vjtM7b4Nslit0wEJ/WkvMKlYRsDALSALy+ZymSBUwNt7UmMQc9FZnBvr9m sV94tShOqbTyRAVpwrhe8k5pEvSQAvVvECN5SRYHzgCmN+1m1XLSzOUeeHTZJhxn SoPnl6aBQOBAR6aqZZgJJzDqXciuBP5VL4kDE= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2583B7525E; Thu, 5 Nov 2009 13:49:48 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 3ABB17525C; Thu, 5 Nov 2009 13:49:46 -0500 (EST) Message-ID: <4AF31E77.4010602@pobox.com> Date: Thu, 05 Nov 2009 10:50:31 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Marsh Ray References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <054CC553-7D2E-435E-ADE3-4FBE7B2DB3F8@rtfm.com> <4AF24942.2090809@extendedsubset.com> In-Reply-To: <4AF24942.2090809@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: FE03A996-CA3B-11DE-AB18-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:49:28 -0000 Excerpt from the PDF: > char *req = > "GET /highsecurity/index.html HTTP/1.1\r\n" > "Host: example.com\r\n" > "Connection: keep-alive\r\n" > "\r\n" > "GET /evil/doEvil.php?evilStuff=here HTTP/1.1\r\n" > "Host: example.com\r\n" > "Connection: close\r\n" > "X-ignore-what-comes-next: "; The attack works because the last line is unterminated to effectively comment out the client's GET request. A possible counter to this attack is for the client to send two CRLF's prior to its actual request. This will separate the evil request from the actual one containing the Cookie. RFC 2616 prohibits this, but suggests that HTTP servers ignore extraneous CRLF's due to buggy HTTP/1.0 clients. In practice, HTTP servers I've tested ignore them. Mike Marsh Ray wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Just out: > > http://extendedsubset.com/?p=8 > > > Eric Rescorla wrote: >> I should also mention his colleague from phonefactor, steve dispensa. > > And I should mention that EKR, as well as some others who frequent this > group, have been invaluable in this process so far. > > I should mention it, but I didn't because I've deliberately left out > names where I didn't have a chance to touch base with the person first. > > Anyway, I hope this info proves to be valuable and timely for the > Hiroshima meeting. > > By the way, I'm available if I can help answer questions on this list, > on the phone, or direct email marsh@extendedsubset.com . > > - - Marsh > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkrySUAACgkQWChJ3x422/KR/gCfcoAZMgD4RsXVUtLinCSDYWnk > 14YAnAmtQWE64+61Z0y5ioh/NM1DoPyz > =YVva > -----END PGP SIGNATURE----- From ekr@rtfm.com Thu Nov 5 10:52:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2DD3A68C3 for ; Thu, 5 Nov 2009 10:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 6vk1AbIc7B9A for ; Thu, 5 Nov 2009 10:52:42 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 92E3F3A62C1 for ; Thu, 5 Nov 2009 10:52:42 -0800 (PST) Received: by yxe30 with SMTP id 30so296769yxe.29 for ; Thu, 05 Nov 2009 10:53:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.54.8 with SMTP id g8mr6990532agk.83.1257447179976; Thu, 05 Nov 2009 10:52:59 -0800 (PST) In-Reply-To: <200911051848.nA5ImQaY004909@fs4113.wdf.sap.corp> References: <200911051848.nA5ImQaY004909@fs4113.wdf.sap.corp> Date: Thu, 5 Nov 2009 10:52:59 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:52:43 -0000 On Thu, Nov 5, 2009 at 10:48 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> I now have a draft extension up > > Thanks Eric. > > =A0Page 5: > > =A0The contents of this extension are specified as follows. > =A0 [...] > =A0The above rules apply even when TLS resumption is used. > > > I read this as meaning that the client and server should add > two elements client.verify_data and server.verify_data > to their SecurityParameters for the connection state suggested > by RFC5246 6.1. and update this data on EVERY TLS handshake, > even TLS session resume. Yes. That's what it means. > =A04.1 =A0Client Considerations > > I can understand what it says, but I _really_ dislike it. > > The root of the problem is servers that perform (or at least allow) > TLS renegotiations and make flawed assumptions about what a > successful TLS renegotiation means for the data previously received. > > What you're essentially asking for, is that a client should no longer > talk TLS to _any_ Server that doesn't support the new extension. > Not even to the good ones that neither offer nor support renegotiation. > > This is discriminating against servers that have been playing safe! > > Essentially we are going to hold TLS clients and the installed > base of good Servers responsible for the broken Servers out there. > That feels very wrong. I'm not recommending that clients do that. What I'm trying to say is that *if* a client wants to be totally sure then all it can do is require the extension. I agree it's impractical (and probably unwise) to suggest that they actuall= y behave that way. Do you agree that the characterization above is correct? If so, how can I update the draft to make that clearer? -Ekr From Nicolas.Williams@sun.com Thu Nov 5 10:57:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403F43A62C1 for ; Thu, 5 Nov 2009 10:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 T3UiihmL+hdW for ; Thu, 5 Nov 2009 10:57:23 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 541793A68C3 for ; Thu, 5 Nov 2009 10:57:23 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5Ivkab006730 for ; Thu, 5 Nov 2009 18:57:46 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 nA5IvjOL014224 for ; Thu, 5 Nov 2009 11:57:45 -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 nA5IkG81009327; Thu, 5 Nov 2009 12:46:16 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5IkGne009326; Thu, 5 Nov 2009 12:46:16 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 12:46:15 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091105184615.GG1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:57:24 -0000 On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote: > I now have a draft extension up at: > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml Initial comments based on a brief skim: - Please add a normative reference to RFC5056. - There's no real need for the ServerHello to include both of the Finished messages from the outer TLS connection. (I think there's no real need for the ServerHello to include either of them, actually, but I've not thought enough about that.) But it's OK as is, of course. - You call for each TLS handshake to bind to the one immediately outside it. Would it be better to bind to the outer-most one instead? (In practice there's probably never more than one outer and one inner handshake, right?) - There is a way for clients to protect themselves even when servers don't implement this extension: a) clients MUST NOT ever send any application-level messages without TLS protection if they are willing to negotiate a TLS connection after sending any application-level messages, _and_, b) if a server requests re-negotiation then the client MUST ensure that the outer and inner TLS connection handshakes used a server certificate, and, specifically, the _same_ server certificate, otherwise the client MUST abort without ever completing the second/inner handshake. This should be stated as it is a helpful workaround that works without modifying the protocol. It's not a generic solution, and it's a client-side-only solution, which is why it's highly desirable to apply the proposed channel binding solution instead. - Might as well update RFC5246 to indicate that the Finished messages for any connection MUST be exported to applications. Better get this done now. Nico -- From ekr@rtfm.com Thu Nov 5 11:09:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F083A69F5 for ; Thu, 5 Nov 2009 11:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 UDWb71jI7Aid for ; Thu, 5 Nov 2009 11:09:34 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 182833A68C3 for ; Thu, 5 Nov 2009 11:09:32 -0800 (PST) Received: by gxk28 with SMTP id 28so289608gxk.9 for ; Thu, 05 Nov 2009 11:09:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.26.7 with SMTP id d7mr7113728agj.1.1257448191899; Thu, 05 Nov 2009 11:09:51 -0800 (PST) In-Reply-To: <20091105184615.GG1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091105184615.GG1105@Sun.COM> Date: Thu, 5 Nov 2009 11:09:51 -0800 Message-ID: From: Eric Rescorla To: Nicolas Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 19:09:35 -0000 On Thu, Nov 5, 2009 at 10:46 AM, Nicolas Williams wrote: > On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote: >> I now have a draft extension up at: >> >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-reneg= otiate.txt >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-reneg= otiate.xml > > Initial comments based on a brief skim: > > =A0- Please add a normative reference to RFC5056. There's no need for a normative reference here. This mechanism is self-contained. I'd be happy to add an informative reference. > =A0- There's no real need for the ServerHello to include both of the > =A0 Finished messages from the outer TLS connection. =A0(I think there's = no > =A0 real need for the ServerHello to include either of them, actually, > =A0 but I've not thought enough about that.) =A0But it's OK as is, of > =A0 course. The general consensus was that it was harmless and might potentially avoid some reflection logic errors. > =A0- You call for each TLS handshake to bind to the one immediately > =A0 outside it. > > =A0 Would it be better to bind to the outer-most one instead? > > =A0 (In practice there's probably never more than one outer and one inner > =A0 handshake, right?) Why do you think this is an improvement. > =A0- There is a way for clients to protect themselves even when servers > =A0 don't implement this extension: > > =A0 a) clients MUST NOT ever send any application-level messages without > =A0 =A0 =A0TLS protection if they are willing to negotiate a TLS connecti= on > =A0 =A0 =A0after sending any application-level messages, > > =A0 _and_, > > =A0 b) if a server requests re-negotiation then the client MUST ensure > =A0 =A0 =A0that the outer and inner TLS connection handshakes used a serv= er > =A0 =A0 =A0certificate, and, specifically, the _same_ server certificate, > =A0 =A0 =A0otherwise the client MUST abort without ever completing the > =A0 =A0 =A0second/inner handshake. This isn't enough. If you look at the diagram you can see that the client never experiences a renegotiation. > =A0- Might as well update RFC5246 to indicate that the Finished messages > =A0 for any connection MUST be exported to applications. =A0Better get th= is > =A0 done now. This sort of interface issue seems out of scope for the TLS spec. -Ekr From fweimer@bfk.de Thu Nov 5 11:09:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFD13A68C3 for ; Thu, 5 Nov 2009 11:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjL8Y1SJ4Vzd for ; Thu, 5 Nov 2009 11:09:35 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 1C0AB3A69DE for ; Thu, 5 Nov 2009 11:09:31 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1N67iP-0001bd-Jp; Thu, 05 Nov 2009 20:09:49 +0100 Received: by bfk.de with local id 1N67iP-0003uk-GI; Thu, 05 Nov 2009 19:09:49 +0000 To: Michael D'Errico References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <054CC553-7D2E-435E-ADE3-4FBE7B2DB3F8@rtfm.com> <4AF24942.2090809@extendedsubset.com> <4AF31E77.4010602@pobox.com> From: Florian Weimer Date: Thu, 05 Nov 2009 19:09:49 +0000 In-Reply-To: <4AF31E77.4010602@pobox.com> (Michael D'Errico's message of "Thu\, 05 Nov 2009 10\:50\:31 -0800") Message-ID: <82skcspz42.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 19:09:36 -0000 * Michael D'Errico: > Excerpt from the PDF: > >> char *req =3D >> "GET /highsecurity/index.html HTTP/1.1\r\n" >> "Host: example.com\r\n" >> "Connection: keep-alive\r\n" >> "\r\n" >> "GET /evil/doEvil.php?evilStuff=3Dhere HTTP/1.1\r\n" >> "Host: example.com\r\n" >> "Connection: close\r\n" >> "X-ignore-what-comes-next: "; > > The attack works because the last line is unterminated to effectively > comment out the client's GET request. > > A possible counter to this attack is for the client to send two > CRLF's prior to its actual request. This will separate the evil > request from the actual one containing the Cookie. It's very hard to tell if this plugs the vulnerability in all cases. I've written web applications which use an server-internal atemporal request to access future authentication information. While that might seem naive in retrospect, it was the recommended way of adding client certificate authentication without introducing additional round-trips, so I'm probably not the only one who did that. These applications will likely remain vulnerable if you confine splicing to HTTP request message boundaries. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mrex@sap.com Thu Nov 5 11:29:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E383A69EF for ; Thu, 5 Nov 2009 11:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.009 X-Spam-Level: X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=0.240, 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 Dp6T7nTDpFbY for ; Thu, 5 Nov 2009 11:29:08 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2AF323A6994 for ; Thu, 5 Nov 2009 11:29:07 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5JTSVM012418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 20:29:29 +0100 (MET) From: Martin Rex Message-Id: <200911051929.nA5JTSaR007035@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 5 Nov 2009 20:29:28 +0100 (MET) In-Reply-To: <20091105184615.GG1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 12:46:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 19:29:09 -0000 Nicolas Williams wrote: > > Initial comments based on a brief skim: > > - Please add a normative reference to RFC5056. I admit to not know what that exactly means, but it sounds wrong. It is perfectly possible to write this document in a fashion that an implementor does NOT NEED to read rfc5056, and therefore I would strongly prefer to keep it that way. > > - There's no real need for the ServerHello to include both of the > Finished messages from the outer TLS connection. (I think there's no > real need for the ServerHello to include either of them, actually, > but I've not thought enough about that.) But it's OK as is, of > course. The Server should send back something different than on initial connect in order to indicate to the client that it is convinced this is a renegotiation rather than an initial handshake. Sending back the verify_data from Server finished seems fair to me. > > - You call for each TLS handshake to bind to the one immediately > outside it. > > Would it be better to bind to the outer-most one instead? I prefer it the way it is currently described, referencing the predecessor. > > (In practice there's probably never more than one outer and one inner > handshake, right?) Technically, there can NEVER be more than two, as required by the TLS spec (there is only one current and one pending) so technically, the existing proposal is referencing the "outer-most" TLS session. You were probably asking for the first TLS-handshake on a connection? The existing proposal looks like less code to me. > > - There is a way for clients to protect themselves even when servers > don't implement this extension: I would hope there is a way, but I have not seen one so far! There are actually two different scenarios: the one I suggested where both sides, client and server perform a renegotiation, and the one described by Marsh, where a clients initial TLS handshake is proxied into a renegotiation for the server. Without a change of the server, the client has certain difficulties to determine whether it is participating in an initial TLS handshake or being proxied into a renegotiation in Marsh's scenario. There are certain safeguards a client can apply (but which are not currently advised by the spec, so are unlikely to be implemented in existing clients. A TLS client could insist on a server credential to not change during a renegotiation. That helps for my scenario, but not for that of Marsh. A TLS client should probably not accept a HelloRequest and neither a CertificateRequest message on a server-anonymous TLS session (DH_anon). > > - Might as well update RFC5246 to indicate that the Finished messages > for any connection MUST be exported to applications. Better get this > done now. I haven't sufficiently thought about this to like it. Adding the finished messages to the renegotiation handshake is fine, because they have originally exchanged under the protection of the currently active ciphersuite, so this should have zero impact. You're asking to make something available that has not been previously available to the application. This might be harmless, but I don't know. -Martin From mrex@sap.com Thu Nov 5 12:21:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007A93A67AF for ; Thu, 5 Nov 2009 12:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 kQjgM+rwPJfg for ; Thu, 5 Nov 2009 12:21:24 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D10C13A6782 for ; Thu, 5 Nov 2009 12:21:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5KLjtv017450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 21:21:45 +0100 (MET) From: Martin Rex Message-Id: <200911052021.nA5KLiAu010298@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 5 Nov 2009 21:21:44 +0100 (MET) In-Reply-To: <20091105182625.GE1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 12:26:26 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:21:25 -0000 Nicolas Williams wrote: > > On Thu, Nov 05, 2009 at 07:16:02PM +0100, Martin Rex wrote: > > Nicolas Williams wrote: > > > You can't use the client.random and server.random as channel bindings. > > > > I'm trying to use terminology that is already in the TLS specs. > > The generic term "channel bindings" is a little bit to fuzzy for > > my taste, and the original use of channel bindings in GSS-API > > is not cryptographically secure. > > I understand. The spec will just have to be updated to say that the > finished messages (or at least the client one) are to be exported to > applications. Huh -- wrong topic? Eric's proposal to make renegotiation secure does not need any API-level changes, everything is completely internal to the TLS protocol engine. What you're looking for might be necessary for application-level channel bindings, but that is a different topic. I don't mind discussing this, but I would appreciate if you identify the topic/solution that you're discussing. ;-) > > I perfectly understand, and _share_, the > desire to use existing interfaces where possible. In this case there is > no such interface (in some TLS APIs apps could parse the TLS record > layer and heuristically find the record that contains the protected > client Finished message, but that's... not really an interface, not what > we wnat, and not reliably available everywhere). On the network, the finished messages are protected under the negotiated ciphersuite. Eric's proposal used the verify_data in its decrypted form, and I thought you were asking for these as well. > > We've looked at this problem many times before, and this is always the > conclusion that we've come to. I really wish that TLS 1.2 had made the > client Finished messages part of the exported security parameters (I > really wish I'd thought to make sure that 1.2 did that). But then, > making the 1.2 spec say this is not enough: installed base inertia is > what makes it hard to ensure that Finished messages are exported. Exported security parameters? Your desire to get your hands on the finished message from the App layer for channel binding purposes is an API issue. The TLS-specs describe only bits-on-the-wire, protocol semantics and TLS session state management. The TLS specs are entirely silent on API issues. (The IETF does not do APIs, and GSS-API is an exception.) -Martin From Nicolas.Williams@sun.com Thu Nov 5 12:32:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBBC23A69C0 for ; Thu, 5 Nov 2009 12:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 WXIpuKTvRMJb for ; Thu, 5 Nov 2009 12:32:44 -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 532C43A69E1 for ; Thu, 5 Nov 2009 12:32:44 -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 nA5KX20w006034 for ; Thu, 5 Nov 2009 20:33:02 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 nA5KX2Og015310 for ; Thu, 5 Nov 2009 13:33:02 -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 nA5KLVao009353; Thu, 5 Nov 2009 14:21:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5KLVvR009352; Thu, 5 Nov 2009 14:21:31 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 14:21:31 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091105202130.GH1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091105184615.GG1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:32:45 -0000 On Thu, Nov 05, 2009 at 11:09:51AM -0800, Eric Rescorla wrote: > On Thu, Nov 5, 2009 at 10:46 AM, Nicolas Williams > wrote: > > On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote: > >> I now have a draft extension up at: > >> > >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml > > > > Initial comments based on a brief skim: > > > > - Please add a normative reference to RFC5056. > > There's no need for a normative reference here. This mechanism is > self-contained. > I'd be happy to add an informative reference. That's also true about draft-altman-tls-channel-bindings then, but you have a normative reference to it. I'm happy with an informative reference. > > - There's no real need for the ServerHello to include both of the > > Finished messages from the outer TLS connection. (I think there's no > > real need for the ServerHello to include either of them, actually, > > but I've not thought enough about that.) But it's OK as is, of > > course. > > The general consensus was that it was harmless and might potentially > avoid some reflection logic errors. If the server sends anything other than a mere acknowledgement, it should send its Finished message from the outer connection -- the client can then check that to see that the server really does understand this -- and the doc should say that the client must check this (but I think it does say this). The server sending the client's Finished message back is superfluous, but I agree that it's harmless. > > - You call for each TLS handshake to bind to the one immediately > > outside it. > > > > Would it be better to bind to the outer-most one instead? > > > > (In practice there's probably never more than one outer and one inner > > handshake, right?) > > Why do you think this is an improvement. Either way the binding would ultimately be to the outer-most connection, therefore this way there's less state to track. A minor point, I agree. > > - There is a way for clients to protect themselves even when servers > > don't implement this extension: > > > > a) clients MUST NOT ever send any application-level messages without > > TLS protection if they are willing to negotiate a TLS connection > > after sending any application-level messages, > > > > _and_, > > > > b) if a server requests re-negotiation then the client MUST ensure > > that the outer and inner TLS connection handshakes used a server > > certificate, and, specifically, the _same_ server certificate, > > otherwise the client MUST abort without ever completing the > > second/inner handshake. > > This isn't enough. If you look at the diagram you can see that the > client never experiences a renegotiation. That's one diagram. There's other cases, but even in the case you described, if the client never experiences a re-negotiation then it will not have authenticated itself, or, if it has authenticated itself then it will/should also have authenticated the server to the client, in which case the MITM can't be. As a result the MITM gets nothing. (My rules cover the case where a client would send a request unprotected, then negotiates TLS when the server requires authentication -- my rules forbid that.) > > - Might as well update RFC5246 to indicate that the Finished messages > > for any connection MUST be exported to applications. Better get this > > done now. > > This sort of interface issue seems out of scope for the TLS spec. Let me re-phrase: the finished messages should be added to SecurityParameters (Martin evidently takes that to be something should be exported to apps; I don't entirely agree with Martin on that point). Nico -- From Nicolas.Williams@sun.com Thu Nov 5 12:41:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3273A6889 for ; Thu, 5 Nov 2009 12:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 U4h3RjPtkYZ1 for ; Thu, 5 Nov 2009 12:41:56 -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 E348E3A67AD for ; Thu, 5 Nov 2009 12:41:56 -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 nA5KgGia023285 for ; Thu, 5 Nov 2009 20:42:16 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 nA5KgGGf021172 for ; Thu, 5 Nov 2009 13:42:16 -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 nA5KUj2N009361; Thu, 5 Nov 2009 14:30:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5KUjQL009360; Thu, 5 Nov 2009 14:30:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 14:30:45 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105203044.GI1105@Sun.COM> References: <20091105184615.GG1105@Sun.COM> <200911051929.nA5JTSaR007035@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911051929.nA5JTSaR007035@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:41:57 -0000 On Thu, Nov 05, 2009 at 08:29:28PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > Initial comments based on a brief skim: > > > > - Please add a normative reference to RFC5056. > > I admit to not know what that exactly means, but it sounds wrong. > > It is perfectly possible to write this document in a fashion that > an implementor does NOT NEED to read rfc5056, and therefore I > would strongly prefer to keep it that way. Referencing RFC5056 wouldn't so much be to provide guidance to implementors as to say "this document conforms to RFC5056". > > - There's no real need for the ServerHello to include both of the > > Finished messages from the outer TLS connection. (I think there's no > > real need for the ServerHello to include either of them, actually, > > but I've not thought enough about that.) But it's OK as is, of > > course. > > The Server should send back something different than on initial > connect in order to indicate to the client that it is convinced > this is a renegotiation rather than an initial handshake. Indeed, it must send something. Even one bit will do -- that was my point. > Sending back the verify_data from Server finished seems fair to me. I agree -- that allows the client to verify that the server did something more than agree. There's no point in the server sending back the client's Finished message though -- that adds no value and wastes space on the wire (very little, granted). > > (In practice there's probably never more than one outer and one inner > > handshake, right?) > > Technically, there can NEVER be more than two, as required by the TLS > spec (there is only one current and one pending) so technically, the > existing proposal is referencing the "outer-most" TLS session. Interesting. > > - There is a way for clients to protect themselves even when servers > > don't implement this extension: > > I would hope there is a way, but I have not seen one so far! > > There are actually two different scenarios: > the one I suggested where both sides, client and server perform > a renegotiation, and the one described by Marsh, where a clients > initial TLS handshake is proxied into a renegotiation for the > server. Ah. I was considering only one of those attacks. You're correct, there is no workaround short of fixing the protocol. > > - Might as well update RFC5246 to indicate that the Finished messages > > for any connection MUST be exported to applications. Better get this > > done now. > > I haven't sufficiently thought about this to like it. > > Adding the finished messages to the renegotiation handshake > is fine, because they have originally exchanged under the protection > of the currently active ciphersuite, so this should have zero impact. For an implementation like Microsoft's SSPI-based implementation TLS that might not be true, since there each TLS connection is represented by a separate "security context" -- for such an implementation the fix requires that the application help the implementation link those security contexts. > You're asking to make something available that has not been previously > available to the application. This might be harmless, but I don't know. How could it not be harmless? What damage could ensue from making the Finished messages of a TLS connection available to the application? Remember: there are cipher suites that provide only integrity protection, therefore Finished messages must not leak any information about the master secret (and indeed, they do not, module the cryptographic strength of the relevant algorithms used in the Finished message construction). Nico -- From Nicolas.Williams@sun.com Thu Nov 5 12:42:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A7D3A68DB for ; Thu, 5 Nov 2009 12:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 277uUWZpLFnw for ; Thu, 5 Nov 2009 12:42:48 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 9DD4C3A68C8 for ; Thu, 5 Nov 2009 12:42:48 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5KhBEm001453 for ; Thu, 5 Nov 2009 20:43:11 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 nA5KhASD021652 for ; Thu, 5 Nov 2009 13:43:10 -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 nA5KVdve009367; Thu, 5 Nov 2009 14:31:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5KVdp2009366; Thu, 5 Nov 2009 14:31:39 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 14:31:39 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091105203139.GJ1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091105184615.GG1105@Sun.COM> <20091105202130.GH1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091105202130.GH1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:42:49 -0000 On Thu, Nov 05, 2009 at 02:21:31PM -0600, Nicolas Williams wrote: > On Thu, Nov 05, 2009 at 11:09:51AM -0800, Eric Rescorla wrote: > > On Thu, Nov 5, 2009 at 10:46 AM, Nicolas Williams > > > [...] > > > > This isn't enough. If you look at the diagram you can see that the > > client never experiences a renegotiation. > > That's one diagram. There's other cases, but even in the case you Oh, never mind. I missed one attack scenario, the one in your doc. Nico -- From Nicolas.Williams@sun.com Thu Nov 5 12:49:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4153A68D6 for ; Thu, 5 Nov 2009 12:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_66=0.6, 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 iE0JxI6TOyw3 for ; Thu, 5 Nov 2009 12:49:26 -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 6C4D43A68C8 for ; Thu, 5 Nov 2009 12:49:26 -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 nA5KnmcY029577 for ; Thu, 5 Nov 2009 20:49:48 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 nA5Knmft026469 for ; Thu, 5 Nov 2009 13:49:48 -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 nA5KcHLL009374; Thu, 5 Nov 2009 14:38:17 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5KcHFL009373; Thu, 5 Nov 2009 14:38:17 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 14:38:17 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105203817.GK1105@Sun.COM> References: <20091105182625.GE1105@Sun.COM> <200911052021.nA5KLiAu010298@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911052021.nA5KLiAu010298@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:49:27 -0000 On Thu, Nov 05, 2009 at 09:21:44PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > On Thu, Nov 05, 2009 at 07:16:02PM +0100, Martin Rex wrote: > > > Nicolas Williams wrote: > > > > You can't use the client.random and server.random as channel bindings. > > > > > > I'm trying to use terminology that is already in the TLS specs. > > > The generic term "channel bindings" is a little bit to fuzzy for > > > my taste, and the original use of channel bindings in GSS-API > > > is not cryptographically secure. > > > > I understand. The spec will just have to be updated to say that the > > finished messages (or at least the client one) are to be exported to > > applications. > > Huh -- wrong topic? Not really. Eric's view seems to be that the TLS spec should say nothing about this. I think it should, for the simple reason that it will help prevent this sort of problem in the future. > > I perfectly understand, and _share_, the > > desire to use existing interfaces where possible. In this case there is > > no such interface (in some TLS APIs apps could parse the TLS record > > layer and heuristically find the record that contains the protected > > client Finished message, but that's... not really an interface, not what > > we wnat, and not reliably available everywhere). > > On the network, the finished messages are protected under the negotiated > ciphersuite. Eric's proposal used the verify_data in its decrypted > form, and I thought you were asking for these as well. You misunderstood the parenthetical. The point was that one might think that apps could get at the Finished messages without help, but in reality they could only get at the protected Finished message, and only if the TLS API was such that the apps could see the TLS record protocol directly, and then only by implementing a heuristic -- all of which is something we _don't_ want. I wrote that parenthetical to preempt anyone saying "why don't you just do [what the text in paren. talked about]?". > The TLS-specs describe only bits-on-the-wire, protocol semantics > and TLS session state management. The TLS specs are entirely > silent on API issues. (The IETF does not do APIs, and GSS-API > is an exception.) Wrong. The GSS-API is NOT the only exception. There's also SCTP, and probably a number of otheres (heck, even IDNA has an abstract API). Nico -- From ekr@rtfm.com Thu Nov 5 12:55:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950903A68EC for ; Thu, 5 Nov 2009 12:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 3O9qNTgkEUwn for ; Thu, 5 Nov 2009 12:55:18 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 7C9813A682E for ; Thu, 5 Nov 2009 12:55:18 -0800 (PST) Received: by yxe30 with SMTP id 30so412733yxe.29 for ; Thu, 05 Nov 2009 12:55:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.41.17 with SMTP id o17mr6214373ago.35.1257454538356; Thu, 05 Nov 2009 12:55:38 -0800 (PST) In-Reply-To: <20091105202130.GH1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091105184615.GG1105@Sun.COM> <20091105202130.GH1105@Sun.COM> Date: Thu, 5 Nov 2009 12:55:38 -0800 Message-ID: From: Eric Rescorla To: Nicolas Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:55:19 -0000 On Thu, Nov 5, 2009 at 12:21 PM, Nicolas Williams wrote: > On Thu, Nov 05, 2009 at 11:09:51AM -0800, Eric Rescorla wrote: >> On Thu, Nov 5, 2009 at 10:46 AM, Nicolas Williams >> wrote: >> > On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote: >> >> I now have a draft extension up at: >> >> >> >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-re= negotiate.txt >> >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-re= negotiate.xml >> > >> > Initial comments based on a brief skim: >> > >> > =A0- Please add a normative reference to RFC5056. >> >> There's no need for a normative reference here. This mechanism is >> self-contained. >> I'd be happy to add an informative reference. > > That's also true about draft-altman-tls-channel-bindings then, but you > have a normative reference to it. =A0I'm happy with an informative > reference. That's an editing error. I'll add informative to both. >> > =A0- There is a way for clients to protect themselves even when server= s >> > =A0 don't implement this extension: >> > >> > =A0 a) clients MUST NOT ever send any application-level messages witho= ut >> > =A0 =A0 =A0TLS protection if they are willing to negotiate a TLS conne= ction >> > =A0 =A0 =A0after sending any application-level messages, >> > >> > =A0 _and_, >> > >> > =A0 b) if a server requests re-negotiation then the client MUST ensure >> > =A0 =A0 =A0that the outer and inner TLS connection handshakes used a s= erver >> > =A0 =A0 =A0certificate, and, specifically, the _same_ server certifica= te, >> > =A0 =A0 =A0otherwise the client MUST abort without ever completing the >> > =A0 =A0 =A0second/inner handshake. >> >> This isn't enough. If you look at the diagram you can see that the >> client never experiences a renegotiation. > > That's one diagram. =A0There's other cases, but even in the case you > described, if the client never experiences a re-negotiation then it will > not have authenticated itself, or, if it has authenticated itself then > it will/should also have authenticated the server to the client, in > which case the MITM can't be. =A0As a result the MITM gets nothing. =A0(M= y > rules cover the case where a client would send a request unprotected, > then negotiates TLS when the server requires authentication -- my rules > forbid that.) You're assuming that certificate-based client auth is the only issue. But the attacker can do damage just by injecting a prefix to an ordinary cookie-authenticated request. -Ekr From ekr@rtfm.com Thu Nov 5 12:57:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13AB33A63D3 for ; Thu, 5 Nov 2009 12:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 8P2iJXnYIfyO for ; Thu, 5 Nov 2009 12:57:04 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 2A6A83A67FA for ; Thu, 5 Nov 2009 12:57:04 -0800 (PST) Received: by ywh13 with SMTP id 13so415367ywh.29 for ; Thu, 05 Nov 2009 12:57:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.26.7 with SMTP id d7mr7342615agj.1.1257454643547; Thu, 05 Nov 2009 12:57:23 -0800 (PST) In-Reply-To: References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091105184615.GG1105@Sun.COM> <20091105202130.GH1105@Sun.COM> Date: Thu, 5 Nov 2009 12:57:23 -0800 Message-ID: From: Eric Rescorla To: Nicolas Williams Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:57:05 -0000 FWIW, here's my more complete analysis. -Ekr From ekr@rtfm.com Thu Nov 5 12:57:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8E73A68C8 for ; Thu, 5 Nov 2009 12:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 L55duHirvdNi for ; Thu, 5 Nov 2009 12:57:48 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 6DB193A682E for ; Thu, 5 Nov 2009 12:57:48 -0800 (PST) Received: by yxe30 with SMTP id 30so415053yxe.29 for ; Thu, 05 Nov 2009 12:58:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.216.7 with SMTP id o7mr6279752agg.45.1257454688476; Thu, 05 Nov 2009 12:58:08 -0800 (PST) In-Reply-To: References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091105184615.GG1105@Sun.COM> <20091105202130.GH1105@Sun.COM> Date: Thu, 5 Nov 2009 12:58:08 -0800 Message-ID: From: Eric Rescorla To: Nicolas Williams Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:57:49 -0000 well, that was really complete, but the link below is even more so! http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html On Thu, Nov 5, 2009 at 12:57 PM, Eric Rescorla wrote: > FWIW, here's my more complete analysis. > > -Ekr > From n.mavrogiannopoulos@gmail.com Thu Nov 5 13:01:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04F73A67DF for ; Thu, 5 Nov 2009 13:01:31 -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 ErFhDlLo1jcX for ; Thu, 5 Nov 2009 13:01:31 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id ABCD63A67B0 for ; Thu, 5 Nov 2009 13:01:30 -0800 (PST) Received: by bwz23 with SMTP id 23so451853bwz.29 for ; Thu, 05 Nov 2009 13:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=tl2QjYCfeENtfGEdrIWCDPCHnkVHZHNHb2k7QrH3x9Y=; b=JjkpzLc8zVqt1vwZV4JrwwVnfPzy3ybyvgCtWgMDvtnc6sJtDANffOsW6GMEEbk9FN oqzLBa/A/86Wt+pjv/+3JY0WMuIXSq7FvFqnUu8CMvPezGTiJenUiA3EuWbnU8d6wy3j ZmSYL9m5vtGnZUA8TlDG0Vl8Qcu8EvoYCyPrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=qjXqF+gGgoMR4Wgk9dC2VfnC0zAyHFnluy0YGJXFn9sXQb+Yab+j1VpIEYV45nQ3V6 4wuGlIQW10FTwnu62crK0N/1ol8QyyRnnQMupXxOK1RqEBDx/q0G1cDBHdWEEThDSPTh gp96vzrY7xB4UFk8lb85MeRddqDoRJHiRw0xw= Received: by 10.204.153.217 with SMTP id l25mr1608332bkw.108.1257454908912; Thu, 05 Nov 2009 13:01:48 -0800 (PST) Received: from ?10.100.1.196? (adsl5-183.ath.forthnet.gr [77.49.196.183]) by mx.google.com with ESMTPS id 21sm2796269fks.39.2009.11.05.13.00.57 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 13:00:57 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4AF33D07.7040100@gnutls.org> Date: Thu, 05 Nov 2009 23:00:55 +0200 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Eric Rescorla References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> In-Reply-To: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: [TLS] TLS or HTTP issue? (was: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:01:32 -0000 Eric Rescorla wrote: > TLS WG members will want to check out this announcement of a > new attack on the TLS renegotiation logic. See here: > > http://www.extendedsubset.com/ > > The high-level summary is that the attacker negotiates TLS with the > server and then subsequently proxies the client's negotiation *over* > that channel. This allows the attacker to inject arbitrary content of > their choice in front of data sent from the TLS client to the TLS > server. This data will be treated by the server as if it came from the > client. Once the new handshake has finished, the attacker can't > do anything else useful. I'll become a bit pedantic and note here that this isn't really a TLS issue. We have an initial server-authenticated only session and some renegotiation of parameters over it to authenticate the client. However TLS doesn't guarantee[0] that if the renegotiation is successful authenticating the client, then the data from the initial session were also by the same authenticated client. Think for example a session that it is anonymous (DH). Why one should assume that commands over the anonymous connection are to be trusted if a successful renegotiation follows? So for me the issue is on HTTP's usage of the TLS protocol renegotiation. After a TLS renegotiation for authentication the previous command cache should have been cleared and reissued after negotiation. I like the fix in TLS though. As I understand it is a way for the clients and servers to keep some state between negotiations, which is a good thing and actually seems to give the guarantee above. regards, Nikos [0]. or is it mentioned somewhere I didn't notice? From yngve@opera.com Thu Nov 5 13:44:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022783A69D7 for ; Thu, 5 Nov 2009 13:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 JAC3hA0bprXO for ; Thu, 5 Nov 2009 13:44:21 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id C98143A6807 for ; Thu, 5 Nov 2009 13:44:20 -0800 (PST) Received: from acorna.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nA5Lho0V002444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Nov 2009 21:43:52 GMT Date: Thu, 05 Nov 2009 22:44:37 +0100 To: "tls@ietf.org" From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.65 (Win32) Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:44:22 -0000 On Thu, 05 Nov 2009 19:16:11 +0100, Eric Rescorla wrote: > I now have a draft extension up at: > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml Does anyone have a public testserver up and running yet? -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From mrex@sap.com Thu Nov 5 13:56:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD443A690F for ; Thu, 5 Nov 2009 13:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=0.214, 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 EmAN8-TYKx9D for ; Thu, 5 Nov 2009 13:56:25 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 4C8833A689F for ; Thu, 5 Nov 2009 13:56:25 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5Lukq2012258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 22:56:47 +0100 (MET) From: Martin Rex Message-Id: <200911052156.nA5LujHw015785@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 5 Nov 2009 22:56:45 +0100 (MET) In-Reply-To: <20091105203817.GK1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 02:38:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:56:26 -0000 Nicolas Williams wrote: > > > Nicolas Williams wrote: > > > > > > I understand. The spec will just have to be updated to say that the > > > finished messages (or at least the client one) are to be exported to > > > applications. > > Eric's view seems to be that the TLS spec should say nothing about this. I fully agree with Eric. IMHO, this proposal should become integral part of rfc5246bis. For the channel bindings topic, in particular when it starts discussing API issues, I personally would prefer when it remains in a seperate document. > > > The TLS-specs describe only bits-on-the-wire, protocol semantics > > and TLS session state management. The TLS specs are entirely > > silent on API issues. (The IETF does not do APIs, and GSS-API > > is an exception.) > > Wrong. The GSS-API is NOT the only exception. There's also SCTP, and > probably a number of otheres (heck, even IDNA has an abstract API). Well, OK. While I was actively participating IETF meeting (1995-1998) it was pointed out several times in IETF plenaries by IESG members that the IETF does not do APIs and GSS-API was an exception. I seem to have missed that this has changed. -Martin From Nicolas.Williams@sun.com Thu Nov 5 14:17:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C753A68E9 for ; Thu, 5 Nov 2009 14:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.033, 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 1dw4vpoFZAN0 for ; Thu, 5 Nov 2009 14:17:53 -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 B75353A6836 for ; Thu, 5 Nov 2009 14:17:53 -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 nA5MIG61008548 for ; Thu, 5 Nov 2009 22:18:16 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 nA5MIF6P020339 for ; Thu, 5 Nov 2009 15:18:16 -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 nA5M6fal009601; Thu, 5 Nov 2009 16:06:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5M6fUl009600; Thu, 5 Nov 2009 16:06:41 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 16:06:41 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105220641.GM1105@Sun.COM> References: <20091105203817.GK1105@Sun.COM> <200911052156.nA5LujHw015785@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911052156.nA5LujHw015785@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 22:17:54 -0000 On Thu, Nov 05, 2009 at 10:56:45PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > Wrong. The GSS-API is NOT the only exception. There's also SCTP, and > > probably a number of otheres (heck, even IDNA has an abstract API). > > Well, OK. > > While I was actively participating IETF meeting (1995-1998) it was > pointed out several times in IETF plenaries by IESG members that > the IETF does not do APIs and GSS-API was an exception. > > I seem to have missed that this has changed. I don't think it was ever really true that "the IETF doesn't do APIs". There have been many people who've said that, but I don't think it was ever the case that the IETF explicitly said it wouldn't (i.e., there are no RFCs, historic or otherwise, saying that). It was always just a canard. Nico -- From marsh@extendedsubset.com Thu Nov 5 14:28:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221A228C128 for ; Thu, 5 Nov 2009 14:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 nK65PI8kt-w1 for ; Thu, 5 Nov 2009 14:28:37 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 584D028C125 for ; Thu, 5 Nov 2009 14:28:37 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6Ap9-000EHg-QF for tls@ietf.org; Thu, 05 Nov 2009 22:28:59 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2CC6B6678 for ; Thu, 5 Nov 2009 22:28:58 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18bXp0F28S+kiYUwsmuBF0UGpbCjBs6Hew= Message-ID: <4AF351A9.30409@extendedsubset.com> Date: Thu, 05 Nov 2009 16:28:57 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <20091105203817.GK1105@Sun.COM> <200911052156.nA5LujHw015785@fs4113.wdf.sap.corp> <20091105220641.GM1105@Sun.COM> In-Reply-To: <20091105220641.GM1105@Sun.COM> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 22:28:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > I don't think it was ever really true that "the IETF doesn't do APIs". I would add here that if the IETF had compared the way TLS looks on the wire with how it is presented by SSL APIs in practice, this defect could not have gone unnoticed. - - Marsh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrzUacACgkQWChJ3x422/LPigCfUI1+6ZYG4bjxQ6ADs6Aqk1rS P2AAoJ3Lt+88E9c/mmth+REKckZnlHKb =1t7R -----END PGP SIGNATURE----- From Nicolas.Williams@sun.com Thu Nov 5 14:50:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226473A6921 for ; Thu, 5 Nov 2009 14:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.032, 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 HFDAt-d5Mjzo for ; Thu, 5 Nov 2009 14:50:11 -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 5D54E3A691C for ; Thu, 5 Nov 2009 14:50:11 -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 nA5MoWiU007271 for ; Thu, 5 Nov 2009 22:50:32 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 nA5MoVWa040059 for ; Thu, 5 Nov 2009 15:50:31 -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 nA5MVUh9009628; Thu, 5 Nov 2009 16:31:30 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5MVU0M009627; Thu, 5 Nov 2009 16:31:30 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 16:31:30 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091105223130.GN1105@Sun.COM> References: <20091105203817.GK1105@Sun.COM> <200911052156.nA5LujHw015785@fs4113.wdf.sap.corp> <20091105220641.GM1105@Sun.COM> <4AF351A9.30409@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF351A9.30409@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 22:50:12 -0000 On Thu, Nov 05, 2009 at 04:28:57PM -0600, Marsh Ray wrote: > Nicolas Williams wrote: > > I don't think it was ever really true that "the IETF doesn't do APIs". > > I would add here that if the IETF had compared the way TLS looks on the > wire with how it is presented by SSL APIs in practice, this defect could > not have gone unnoticed. Indeed. Larry Zhu described to me how the SSPI models TLS just a few days ago. I should have noticed immediately the lack of binding, but because I wasn't also thinking of HTTPS, I didn't. I'd go far enough to say that we must consider at least abstract APIs to protocols such as TLS. Nico -- From Nicolas.Williams@sun.com Thu Nov 5 15:14:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD223A67E2 for ; Thu, 5 Nov 2009 15:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.032, 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 mFuVIU5jWzOb for ; Thu, 5 Nov 2009 15:14:52 -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 396253A67DF for ; Thu, 5 Nov 2009 15:14:52 -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 nA5NFEjb027552 for ; Thu, 5 Nov 2009 23:15:15 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 nA5NFE1D039993 for ; Thu, 5 Nov 2009 16:15:14 -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 nA5N3iR8009645; Thu, 5 Nov 2009 17:03:44 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5N3imO009644; Thu, 5 Nov 2009 17:03:44 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 17:03:44 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091105230343.GO1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:14:53 -0000 On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote: > I now have a draft extension up at: > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml > > Comments welcome. More comments: - Consider an implementation like Windows' SSPI-based implementation. Or, for that matter, the old GGF (Global Grid Forum) GSS-API interface to TLS. In such an implementation each TLS connection is a distinct "security context". So in the re-negotiation case there are two distinct negotiations, each being an application-driven API (i.e., in each case the application calls functions like the GSS-API GSS_Init_sec_context() and GSS_Accept_sec_context()). So how would an implementor with such an API implement your proposal? Like so: 1) Add a function to extract the Finished messages from a TLS "security context". This is trivial to do: it's just a new function, an accessor of security contexts. 2) Add a function or input to the init/accept_sec_context functions by which to pass in, to a new "security context", the Finished messages of another TLS "security context". This can't easily be done as a new accessor-type function -- it has to be a new function argument, which... can't be done, so that one has to simply add new versions of the init/accept_sec_context functions. But wait! The SSPI/GSS-API already have the (2)! And we call it a "channel binding" input. You can see where I'm going with this. It will help keep existing APIs clean if you just stick to the RFC5056 model and call this "channel binding". That is, I propose that you re-shape the proposal as a generic channel binding facility for TLS. The actual changes to the proposal are fairly minor: a) the proposed extension needs to carry an opaque octet string of variable length, b) the server should echo a trivial transformation of the client-provided string. Nico -- From mrex@sap.com Thu Nov 5 15:24:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2DB3A6927 for ; Thu, 5 Nov 2009 15:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.562 X-Spam-Level: X-Spam-Status: No, score=-5.562 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OEM_BRC=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwxug+EwIpOz for ; Thu, 5 Nov 2009 15:24:36 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 528053A6924 for ; Thu, 5 Nov 2009 15:24:36 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5NOuR8015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 00:24:56 +0100 (MET) From: Martin Rex Message-Id: <200911052324.nA5NOtdH021096@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 6 Nov 2009 00:24:55 +0100 (MET) In-Reply-To: <4AF351A9.30409@extendedsubset.com> from "Marsh Ray" at Nov 5, 9 04:28:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:24:37 -0000 Marsh Ray wrote: > > I would add here that if the IETF had compared the way TLS looks on the > wire with how it is presented by SSL APIs in practice, this defect could > not have gone unnoticed. I would like to put this differently. There are several different APIs and API architectures for SSL/TLS protocol stacks. If you really want to verify a spec, there is no better way than implementing it. As an implementor, you get to see both, the TLS protocol engine as well as the API that you make available to application callers. And when an implementer describes to its consumers how to use the implementation and how to architect the applications usage of TLS, this problem should really have been noticed. Finding problems when discussing things at an abstract level is MUCH MUCH harder. You notice that when people define protocols with ASN.1 elements. It's almost exclusively the implementors who find the problems. The (OEM) SSL/TLS library that we ship does not support renegotiation in the server implementation, so I never thought about the implications of using renegotiation on the server side. And when we started shipping SSL, my knowledge about the SSL/TLS protocols was quite limited. My expertise was mostly around GSS-API at that time. -Martin From fluffy@cisco.com Thu Nov 5 15:26:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748FC28B56A for ; Thu, 5 Nov 2009 15:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.405 X-Spam-Level: X-Spam-Status: No, score=-106.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ELC7fBeRk5Ia for ; Thu, 5 Nov 2009 15:26:03 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CD6663A68A9 for ; Thu, 5 Nov 2009 15:26:03 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF/t8kqrR7Ht/2dsb2JhbADJMpd0hD0E X-IronPort-AV: E=Sophos;i="4.44,688,1249257600"; d="scan'208";a="102675204" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 05 Nov 2009 23:26:27 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA5NQPnP029346; Thu, 5 Nov 2009 23:26:26 GMT From: Cullen Jennings To: mrex@sap.com In-Reply-To: <200911052156.nA5LujHw015785@fs4113.wdf.sap.corp> Impp: xmpp:cullenfluffyjennings@jabber.org References: <200911052156.nA5LujHw015785@fs4113.wdf.sap.corp> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 16:26:25 -0700 X-Mailer: Apple Mail (2.936) Cc: ekr@rtfm.com, tls@ietf.org, Nicolas Williams Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:26:04 -0000 On Nov 5, 2009, at 2:56 PM, Martin Rex wrote: > While I was actively participating IETF meeting (1995-1998) it was > pointed out several times in IETF plenaries by IESG members that > the IETF does not do APIs and GSS-API was an exception. As a current member of the IESG, I think I can say that has changed at least a little bit. There are place where the IETF standardizing and API, or abstract level of an API, makes sense - and places where it does not. I imagine the choice to do an API or not would be handled on a case by case basis. I don't have any simple hard and fast advice to offer other than talk to the Sec ADs. From mrex@sap.com Thu Nov 5 15:51:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F6F3A681B for ; Thu, 5 Nov 2009 15:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.222, 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 NXr1YEvIhtrK for ; Thu, 5 Nov 2009 15:51:38 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 4D8513A67A8 for ; Thu, 5 Nov 2009 15:51:38 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5NpxCv014613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 00:51:59 +0100 (MET) From: Martin Rex Message-Id: <200911052351.nA5Npxai022736@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 6 Nov 2009 00:51:59 +0100 (MET) In-Reply-To: <20091105230343.GO1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 05:03:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:51:39 -0000 Nicolas Williams wrote: > > On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote: > > I now have a draft extension up at: > > > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml > > > > Comments welcome. > > More comments: > > - Consider an implementation like Windows' SSPI-based implementation. > Or, for that matter, the old GGF (Global Grid Forum) GSS-API > interface to TLS. This strikes me as really odd! Btw. does GGF really require renegotiation? What is so impossible about asking for a client cert in the initial TLS handshake? I read your message to mean that applications based on architectures like SSPI and GGF will need to modify their code INDEPENDENTLY to how we solve the problem to avoid the security problem as well as to adopt the solution. Why do you insist that we make the change in a fashion that caters a particular API? I would not mind if those TLS implementers with the GGF and SSPI use the terminology and function parameters they formerly called "channel bindings" (AFAIK SSPI doesn't have channel bindings) to pass along the finished messages described in Erics document. I am certainly opposed to adopting one particular API's terminology and confuse other API architectures where there already is an established term for the piece of information that we want to carry over between an existing TLS session and a new TLS session. What I definitely do NOT want here, is make that new box (the TLS extension for secure renegotiation) officially available to the discretion of the application caller, since those applications just demonstrated to act based on extremely flawed assumptions. If you want to do that for your particular implementation, OK. I definitely do not want to see this being recommended or encouraged by the TLS spec. Once bitten, twice shy. > > That is, I propose that you re-shape the proposal as a generic channel > binding facility for TLS. The actual changes to the proposal are fairly > minor: a) the proposed extension needs to carry an opaque octet string > of variable length, b) the server should echo a trivial transformation > of the client-provided string. So for this particular issue we're discussing here, those APIs should build solutions to pass down the security context handle of the "current" TLS session to handshake operations performed by the "pending" TLS session, so that these can retrieve and verify the relevant verify_data structures. For OpenSSL-style APIs the TLS session renegotiation happens (or is denied) transparently on the same SSL session handle. -Martin From mickgray@au1.ibm.com Thu Nov 5 16:00:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D128628C14C for ; Thu, 5 Nov 2009 16:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 HCsoW5UrFn9s for ; Thu, 5 Nov 2009 16:00:23 -0800 (PST) Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by core3.amsl.com (Postfix) with ESMTP id B5BD03A6932 for ; Thu, 5 Nov 2009 16:00:22 -0800 (PST) Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp01.au.ibm.com (8.14.3/8.13.1) with ESMTP id nA5NxCDh028212 for ; Fri, 6 Nov 2009 10:59:12 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nA5NveTi1642576 for ; Fri, 6 Nov 2009 10:57:41 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nA600g4I007905 for ; Fri, 6 Nov 2009 11:00:42 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nA600gNB007900; Fri, 6 Nov 2009 11:00:42 +1100 In-Reply-To: To: Eric Rescorla X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Fri, 6 Nov 2009 10:00:23 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 06/11/2009 11:07:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 00:00:23 -0000 Eric Rescorla wrote: > well, that was really complete, but the link below is even more so! > > http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html > > > On Thu, Nov 5, 2009 at 12:57 PM, Eric Rescorla wrote: > > FWIW, here's my more complete analysis. > > > > -Ekr IMHO The proposed fix looks to be also introducing the concept of Retrospective Trust into TLS. This being necessary due to the problem highlighted in the HTTP protocol in that it will process messages that arrived prior to authentication etc. However, IMHO I would guess that once TLS is perhaps protected, then the attacker will simply attack at some other level as the HTTP/Web Application is still vulnerable. IMHO these other attacks might be easier to do and perhaps at the same time harder to detect. My view is that implying Retrospective Trust in TLS will lure application developers into incorrectly thinking they are now (or are still) safe and continue the IMHO dangerous practice of Retrospective Trust. IMHO I would question why allowing the concept of Retrospective Trust into TLS is not inherently dangerous. Mick Gray P.S. - The opinions above are my own, and not necessarily those of my employer. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Thu Nov 5 16:11:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F69A3A67F3 for ; Thu, 5 Nov 2009 16:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.032, 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 KSGs0MHrSQwa for ; Thu, 5 Nov 2009 16:11:16 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 7358D3A6A03 for ; Thu, 5 Nov 2009 16:11:14 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA60BXUb028362 for ; Fri, 6 Nov 2009 00:11: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 nA60BX6F017798 for ; Thu, 5 Nov 2009 17:11: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 nA6003rU009759; Thu, 5 Nov 2009 18:00:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6002kg009758; Thu, 5 Nov 2009 18:00:02 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 18:00:02 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091106000002.GQ1105@Sun.COM> References: <20091105230343.GO1105@Sun.COM> <200911052351.nA5Npxai022736@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911052351.nA5Npxai022736@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 00:11:17 -0000 On Fri, Nov 06, 2009 at 12:51:59AM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote: > > > I now have a draft extension up at: > > > > > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml > > > > > > Comments welcome. > > > > More comments: > > > > - Consider an implementation like Windows' SSPI-based implementation. > > Or, for that matter, the old GGF (Global Grid Forum) GSS-API > > interface to TLS. > > This strikes me as really odd! What's odd? > Btw. does GGF really require renegotiation? What is so impossible > about asking for a client cert in the initial TLS handshake? Did I say that? No. Please don't read into what I wrote. But note that with a GGF GSS-API-based implementation of TLS you _can_ do re-negotiation! It's simple really. And it shows that there's no link between the inner and outer connections (here, security contexts), except that the outer one protects the inner's hanshake (here, security context token exchange). (Well, also, the app needs to know if the server sent a ChangeCipherSpec message, so that it can switch to using the inner security context for all subsequent wrap tokens.) Nico -- From Nicolas.Williams@sun.com Thu Nov 5 16:15:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C26528C10F for ; Thu, 5 Nov 2009 16:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 Jl9MKN0Z6qQu for ; Thu, 5 Nov 2009 16:15:35 -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 AFFC73A68B3 for ; Thu, 5 Nov 2009 16:15:28 -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 nA60Fno8025713 for ; Fri, 6 Nov 2009 00:15:49 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 nA60Fn4S020036 for ; Thu, 5 Nov 2009 17:15:49 -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 nA5Nun8L009751; Thu, 5 Nov 2009 17:56:49 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5NumgR009750; Thu, 5 Nov 2009 17:56:48 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 17:56:48 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091105235648.GP1105@Sun.COM> References: <4AF351A9.30409@extendedsubset.com> <200911052324.nA5NOtdH021096@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911052324.nA5NOtdH021096@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 00:15:36 -0000 On Fri, Nov 06, 2009 at 12:24:55AM +0100, Martin Rex wrote: > Marsh Ray wrote: > > > > I would add here that if the IETF had compared the way TLS looks on the > > wire with how it is presented by SSL APIs in practice, this defect could > > not have gone unnoticed. > > I would like to put this differently. > > There are several different APIs and API architectures for SSL/TLS > protocol stacks. If you really want to verify a spec, there is > no better way than implementing it. As an implementor, you get > to see both, the TLS protocol engine as well as the API that > you make available to application callers. > > And when an implementer describes to its consumers how to use > the implementation and how to architect the applications usage > of TLS, this problem should really have been noticed. > > > Finding problems when discussing things at an abstract level > is MUCH MUCH harder. You notice that when people define > protocols with ASN.1 elements. It's almost exclusively > the implementors who find the problems. Implementors, on the other hand, may not have the experience necessary to determine the consequences of a flaw like this, they may (and probably did) just shrug. More likely though, you can't really predict who's going to find any given vulnerability. Providing more information, more views, always helps. In this case it would have. But then, too, we should keep in mind that there are many possible TLS API designs -- Marsh is saying, I think, that the SSPI-/ GSS-API-like ones that would have made this flaw obvious, and I agree. From Nicolas.Williams@sun.com Thu Nov 5 16:24:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150F93A67F3 for ; Thu, 5 Nov 2009 16:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 bnlJ70IsLWTY for ; Thu, 5 Nov 2009 16:24:07 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 3547F3A67E2 for ; Thu, 5 Nov 2009 16:24:07 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA60OU82001143 for ; Fri, 6 Nov 2009 00:24:30 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 nA60OTPo023985 for ; Thu, 5 Nov 2009 17:24:29 -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 nA60CxkU009766; Thu, 5 Nov 2009 18:12:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA60Cxxe009765; Thu, 5 Nov 2009 18:12:59 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 18:12:59 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091106001259.GR1105@Sun.COM> References: <20091105230343.GO1105@Sun.COM> <200911052351.nA5Npxai022736@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911052351.nA5Npxai022736@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 00:24:08 -0000 On Fri, Nov 06, 2009 at 12:51:59AM +0100, Martin Rex wrote: > I read your message to mean that applications based on architectures > like SSPI and GGF will need to modify their code INDEPENDENTLY to how > we solve the problem to avoid the security problem as well as to adopt > the solution. Implementations clearly have to change. Implementation with a specific API design that I identified will require application changes to go with the TLS implementation changes. > Why do you insist that we make the change in a fashion that > caters a particular API? [Overlooking you use of the ver "to insist" for a moment...] For two reasons: 1) If it's not onerous for any other implementors, then making a change that makes the fix simpler for some implementors is worth considering; 2) RFC5056 exists and defines channel binding. Channel binding _is_ what the proposed fix here actuall does, but in a way that does not conform to RFC5056, and in a way that does not conform to APIs that have support for channel vbinding work (APIs that can be interfaces to TLS). Not conforming to RFC5056 is hardly fatal. And if some implementors have to do ugly things to their APIs and applications using them, well too bleeping bad. Right? But I have a right to ask for the WG to consider making this fix conform to RFC5056 and not force some implementors to do ugly things to their APIs. Not a right to demand, mind you -- the WG consensus can reject my proposal. Rather than cast this as me "insisting" on something or other, how about debating the actual proposal? Say what you like or dislike about it. See where the chips fall. > I would not mind if those TLS implementers with the GGF and SSPI > use the terminology and function parameters they formerly called > "channel bindings" (AFAIK SSPI doesn't have channel bindings) > to pass along the finished messages described in Erics document. Neither would I. Except that they _can't_ with Eric's proposal, not without violating abstractions and interpreting the contents of the channel bindings input, which is why I object. > I am certainly opposed to adopting one particular API's > terminology and confuse other API architectures where there > already is an established term for the piece of information > that we want to carry over between an existing TLS session > and a new TLS session. Whatever. No one asked that you, or Eric, or the WG or anyone else do that. There's no need to use SSPI or GSS-API terminology in the resulting spec. There is a desire, on _my_ part, for RFC5056 conformance. Nico -- From Nicolas.Williams@sun.com Thu Nov 5 16:40:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B133A6878 for ; Thu, 5 Nov 2009 16:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 BwuWpjKq38n1 for ; Thu, 5 Nov 2009 16:40:36 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 386D83A67DB for ; Thu, 5 Nov 2009 16:40:36 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA60ewB5001828 for ; Fri, 6 Nov 2009 00:40:58 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 nA60ewff031079 for ; Thu, 5 Nov 2009 17:40:58 -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 nA60TSYq009781; Thu, 5 Nov 2009 18:29:28 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA60TSZ3009780; Thu, 5 Nov 2009 18:29:28 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 18:29:28 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091106002928.GS1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091105230343.GO1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091105230343.GO1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 00:40:37 -0000 Note, there's a way to implement Eric's proposal as-is and in an SSPI/GGF-GSS-API way that doesn't suck, but which does require a layering violation, though one that I could live with: - client and server apps both extract the 'tls-unique-for-telnet' channel binding from the outer connection, prefix that with the RFC5056-required prefix, and pass that to the init/accept_sec_context functions. - The TLS init/accept_sec_context implementation checks to see if the channel binding input starts with "tls-unique-for-telnet:" (the RFC5056-required prefix when using that channel binding type), and, if it does, then split the rest of the channel binding input accordingly and use the two halfs as per-Eric's proposal. I can live with that. I'd like to have a generic channel binding facility in TLS. I'd like to not have to implement such a layering violation. Nico -- From mrex@sap.com Thu Nov 5 17:05:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD42628C10D for ; Thu, 5 Nov 2009 17:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, 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 2C05PMmdEw8t for ; Thu, 5 Nov 2009 17:05:29 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6F1D83A6A06 for ; Thu, 5 Nov 2009 17:05:29 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA615kHH027450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 02:05:46 +0100 (MET) From: Martin Rex Message-Id: <200911060105.nA615jen027166@fs4113.wdf.sap.corp> To: mickgray@au1.ibm.com (Michael Gray) Date: Fri, 6 Nov 2009 02:05:45 +0100 (MET) In-Reply-To: from "Michael Gray" at Nov 6, 9 10:00:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 01:05:31 -0000 Michael Gray wrote: > > Eric Rescorla wrote: > > http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html > > IMHO The proposed fix looks to be also introducing the concept of > Retrospective Trust into TLS. This being necessary due to the problem > highlighted in the HTTP protocol in that it will process messages that > arrived prior to authentication etc. To some degree I share your concern. However, I do believe that the the proposed fix to provide secure renegotiation primarily fixes a problem in the TLS protocol, which does not live up to its own promises on security of a TLS session renegotiation. Admittedly, the momentum behind this effort is the prospective blessing this will provide on the current awful practice in this area, because first of all, vendors _and_ implementors are trying to maintain the current level of look&feel / usability -- or maybe we should call it "convenience". If we forgive the applications today, they are going to do even more daring things tomorrow -- and that could be things that we cannot fix easily. In real life, however, security is much more about risk management than absolute security. Bruce Schneier has written at least a dozen good articles about that topic. The more difficult security is to use, the more often people will work around it. I think we should improve on guidance, rather than be totally anal about who goofed which part. > > However, IMHO I would guess that once TLS is perhaps protected, > then the attacker will simply attack at some other level as the > HTTP/Web Application is still vulnerable. IMHO these other > attacks might be easier to do and perhaps at the same time harder to > detect. Just a second! The problem were addressing here is _NOT_ easily detectable. I think it is just the opposite. There has always been an arms race. And I don't see how or why this would change in the future. What exactly do _you_ suggest? That we _not_ fix this issue in TLS, so that the apps can keep pointing on us and do not have to fix their other problems? Is that really going to help? > My view is that implying Retrospective Trust in TLS will lure > application developers into incorrectly thinking they are now (or are > still) safe and continue the IMHO dangerous practice of Retrospective > Trust. IMHO I would question why allowing the concept of Retrospective > Trust into TLS is not inherently dangerous. As inidicated at the beginning, there is some truth in what you're saying. But looking at all aspects of the problem, I don't feel like not fixing this is the bigger evil. But your criticism about the Retrospective Trust is quite valid. It is a dangerous design, and it is questionable that the risk it brings is worth the convenience it offers. Compare it to this real-world scenario: Today, many companies have tight control on who enters their office buildings, and it helps them to manage their risk and gives them some amount of audit and accountability. The Retrospective Trust means that you get rid of that control at the building entrance. Instead, you solely rely on your own perfection to reliably check each and everyone that leaves an office with a binder in his hands. Either he must show his permission or leave without the binder. You regularly find someone without permission, but you're not allowed to ask his name, and a few of them constantly do this and you have no means to keep them out of your building. I would not describe the latter as sensible risk management. It doesn't look very reliable or robust. But if you implement some convenient "permissions check" (hey, rfid is fun, isn't it), it might feel quite convenient for the people that work there. Having to pass a gate one-by-one during rush hour (morning,lunch,evening) often creates a less appealing user experience. -Martin From mrex@sap.com Thu Nov 5 19:14:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE28B3A681F for ; Thu, 5 Nov 2009 19:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.209, 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 gttreWXgM7OS for ; Thu, 5 Nov 2009 19:14:11 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C30783A6783 for ; Thu, 5 Nov 2009 19:14:10 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA63EVNS026856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 04:14:32 +0100 (MET) From: Martin Rex Message-Id: <200911060314.nA63EUtq004352@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 6 Nov 2009 04:14:30 +0100 (MET) In-Reply-To: <20091106001259.GR1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 06:12:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 03:14:12 -0000 Nicolas Williams wrote: > > > I would not mind if those TLS implementers with the GGF and SSPI > > use the terminology and function parameters they formerly called > > "channel bindings" (AFAIK SSPI doesn't have channel bindings) > > to pass along the finished messages described in Erics document. > > Neither would I. Except that they _can't_ with Eric's proposal, not > without violating abstractions and interpreting the contents of the > channel bindings input, which is why I object. The security context iterators (InitializeSecurityContext and AcceptSecurityContext or gss_init_sec_context/gss_accept_sec_context) are designed to exchange opaque tokens between the peers (client and server / initiator and acceptor ) What you are looking for is a token exchange between two security contexts, old and new. Ultimately you could create full blown iterator calls to do this. Or a "cheap" one-token hack like this: GetCarryOverData ( oldsecuritycontext, &opaque_buffer ); CreateSecurityContextWithCarryOver( opaque_buffer, &newsecuritycontext ); ReleaseBuffer( &opaque_buffer ); Or with just a single call: CreateRenegoContext(oldcontext, flags, &newcontext); with a little modification of the init and accept iterators so that they can start with a context handle created by this new call instead of a NULL handle. The latter single-call approach seems the cleanest to me, because it is the most flexible in case we ever find another need to transfer information between an original and renegotiated session -- without having to change apps that use a GSS-API style architecture. And it is the one which is the most difficult to break by careless applications. :) Limiting the evolution of the TLS protocol and the interaction between current and pending session states seems like an unjustified restriction to me. If a particular API has a problem with a useful evolutionary change of TLS, then this might be a design shortcoming in the API and should be fixed there. I don't think we should deny in a very useful way just it might have an impact on certain esoteric API architectures. Comparing the amout of work to (a) technically block the renegotiation in the TLS implementation and (b) replace/update the renegotion with a secure renegotiation for the OpenSSL-style architecture and for the SSPI architecture, it seems that the OpenSSL architecture is not so bad after all. I have never looked at GGF. Does it really create two seperate, unrelated contexts similar to what SSPI does? A while back, a vendor had his GSS-API mechanism certified for interoperability with out application, and he told me that this mechanism was built on top of OpenSSL. I don't know whether they have implemented renegotiation (I doubt it, since that mechanism is not wire-compatible with native SSL due to the GSS-API token framing. But I could conceive a renegotiation architecture without a seperate context handle. Maybe apps shouldn't be sitting straight on top of SSPI? I'm glad we have our thin gsskrb5.dll between our own apps and SSPI, because I had to work around several bugs and backwards incompatible changes during the last 9 years, and that additional abstraction helped me significantly in the logistics of getting updates or workarounds out to the customers. Since we provide gsskrb5.dll as OpenSource, customers could even do that themselves... -Martin From Nicolas.Williams@sun.com Thu Nov 5 19:32:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57BF83A69D8 for ; Thu, 5 Nov 2009 19:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 jiHovmFnFWl3 for ; Thu, 5 Nov 2009 19:32:56 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 35B413A6867 for ; Thu, 5 Nov 2009 19:32:56 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA63XI9X018713 for ; Fri, 6 Nov 2009 03:33:18 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 nA63XIrA054480 for ; Thu, 5 Nov 2009 20:33: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 nA63Ll8R009926; Thu, 5 Nov 2009 21:21:47 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA63Lkp9009925; Thu, 5 Nov 2009 21:21:46 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Nov 2009 21:21:46 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091106032146.GT1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091105230343.GO1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091105230343.GO1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 03:32:57 -0000 On Thu, Nov 05, 2009 at 05:03:44PM -0600, Nicolas Williams wrote: > On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote: > > I now have a draft extension up at: > > > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml > > > > Comments welcome. > > More comments: > > - Consider an implementation like Windows' SSPI-based implementation. > Or, for that matter, the old GGF (Global Grid Forum) GSS-API > interface to TLS. I've thought about this some more. I think now that what I considered a layering violation earlier today actually isn't. A security mechanism that takes an input channel binding, removes the channel binding type prefix then splits the remainder into two octet strings, with each end-point sending one half, is actually conformant to RFC5056. Therefore I have no further objections, and, for now, no further comments. Nico -- From fweimer@bfk.de Fri Nov 6 01:25:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2160F28C17B for ; Fri, 6 Nov 2009 01:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GOLzkgYWasr for ; Fri, 6 Nov 2009 01:25:50 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 2D91E28C175 for ; Fri, 6 Nov 2009 01:25:48 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1N6L56-0005i9-1j; Fri, 06 Nov 2009 10:26:08 +0100 Received: by bfk.de with local id 1N6L55-0003ik-OY; Fri, 06 Nov 2009 09:26:07 +0000 To: Nikos Mavrogiannopoulos References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> From: Florian Weimer Date: Fri, 06 Nov 2009 09:26:07 +0000 In-Reply-To: <4AF33D07.7040100@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu\, 05 Nov 2009 23\:00\:55 +0200") Message-ID: <82639ongwg.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eric Rescorla , "tls@ietf.org" Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 09:25:51 -0000 * Nikos Mavrogiannopoulos: > I'll become a bit pedantic and note here that this isn't really a TLS > issue. I'm not sure. We've got a middleware which provides RPC services over TLS with certificates on both ends, and it happens that we're vulnerable as well[1], even though we require client certificates from the start. Suppose that there is an RPC which is some sort of store operation, allowing reading back the stored data by the client. The attacker pre-loads half of such an RFC call, triggers renegotation, and splices this connection to an unsuspecting client. The client will complete the RPC call, the server will save the call contents (including metadata) as the payload of the store request that precedes it, associated with the attacker's certificate (because it sticks to the certificate it saw first). The attacker can use the service to read back the saved call contents, gaining access to data it would not ordinarily have access to. Theoretically, this attack can be detected by the server, but not using the APIs that are currently deployed. You are right that HTTP is worse, but based on the attack sketched above, the basic issue also affects other services. [1] We've got other safeguards which prevent actual exploitation in our case, but the theoretical vulnerability is still there. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Pasi.Eronen@nokia.com Fri Nov 6 01:40:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8CE28C18B for ; Fri, 6 Nov 2009 01:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 wcXDOjqrREGf for ; Fri, 6 Nov 2009 01:40:02 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 7B11828C18A for ; Fri, 6 Nov 2009 01:40:02 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA69dtw8017264; Fri, 6 Nov 2009 03:40:24 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 11:40:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 11:40:17 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 6 Nov 2009 10:40:18 +0100 From: To: , Date: Fri, 6 Nov 2009 10:40:17 +0100 Thread-Topic: [TLS] Questions about TLS Server Name Indication extension Thread-Index: AcpZz3t23ziuj5D6QbaRdcjzgpkrWgET1NqA Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F81BDAE@NOK-EUMSG-01.mgdnok.nokia.com> References: <200910292246.n9TMk6sZ014367@fs4113.wdf.sap.corp> <4AEB9D27.5090203@pobox.com> In-Reply-To: <4AEB9D27.5090203@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Nov 2009 09:40:17.0947 (UTC) FILETIME=[266916B0:01CA5EC5] X-Nokia-AV: Clean Subject: Re: [TLS] Questions about TLS Server Name Indication extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 09:40:03 -0000 Michael D'Errico wrote: > But that brings up a subtle point. What if the client originally > connected offering a higher version than I support? When it tries > to resume a session, should it use the version it originally sent > in the ClientHello, or the lower version that was negotiated? >=20 > I would think that the client should be allowed to specify the same > version number it originally connected with. >=20 > I searched through RFC 5246 but could not find a discussion of this. > Did I miss it? What do others think should happen? RFC 5246 does say: Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. "SHOULD" seems to allow both cases (and since the server might fall back to full handshake, perhaps it would be better to send the highest version supported by the client...). Best regards, Pasi From Pasi.Eronen@nokia.com Fri Nov 6 01:40:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FD928C148 for ; Fri, 6 Nov 2009 01:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 0YffWUA6hUbQ for ; Fri, 6 Nov 2009 01:40:20 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6F68628C17F for ; Fri, 6 Nov 2009 01:40:20 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA69eUoW001855; Fri, 6 Nov 2009 11:40:33 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 11:40:31 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 11:40:19 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 6 Nov 2009 10:40:19 +0100 From: To: , Date: Fri, 6 Nov 2009 10:40:19 +0100 Thread-Topic: [TLS] Interest in taking draft-seggelmann-tls-dtls-heartbeat-01 as a working group item Thread-Index: Acpdl9NgJElUwV+2Q9+kk6c8I0NEiAAifCwA Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F81BDAF@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Nov 2009 09:40:19.0978 (UTC) FILETIME=[279EFEA0:01CA5EC5] X-Nokia-AV: Clean Subject: Re: [TLS] Interest in taking draft-seggelmann-tls-dtls-heartbeat-01 as a working group item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 09:40:21 -0000 (not wearing any hats) I support this, and am willing to review. Best regards, Pasi > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Joseph Salowey (jsalowey) > Sent: 04 November, 2009 23:43 > To: tls@ietf.org > Subject: [TLS] Interest in taking draft-seggelmann-tls-dtls-heartbeat- > 01 as a working group item >=20 > There has been some interest expressed in > draft-seggelmann-tls-dtls-heartbeat. I'd like to see if there is > enough > to take this up as a TLS working group item. Please respond if you > approve or disapprove taking this on as a working group item. If you > approve please indicate if you are willing to contribute text or > review. >=20 >=20 > Thanks, >=20 > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ietf-ietf-tls@m.gmane.org Fri Nov 6 07:47:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357253A6852 for ; Fri, 6 Nov 2009 07:47:01 -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 jRjlG0O+TOUz for ; Fri, 6 Nov 2009 07:47:00 -0800 (PST) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id D4C523A6991 for ; Fri, 6 Nov 2009 07:46:59 -0800 (PST) Received: from list by lo.gmane.org with local (Exim 4.50) id 1N6R1w-0004iI-9Q for tls@ietf.org; Fri, 06 Nov 2009 16:47:16 +0100 Received: from rain.gmane.org ([80.91.229.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Nov 2009 16:47:16 +0100 Received: from Bruno.Harbulot by rain.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Nov 2009 16:47:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Bruno Harbulot Date: Fri, 06 Nov 2009 15:46:54 +0000 Lines: 74 Message-ID: <4AF444EE.9070401@manchester.ac.uk> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: rain.gmane.org User-Agent: Thunderbird 2.0.0.23 (X11/20090817) In-Reply-To: <4AF33D07.7040100@gnutls.org> Sender: news Cc: Eric Rescorla Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 15:47:01 -0000 Hello, Nikos Mavrogiannopoulos wrote: > Eric Rescorla wrote: >> TLS WG members will want to check out this announcement of a >> new attack on the TLS renegotiation logic. See here: >> >> http://www.extendedsubset.com/ >> >> The high-level summary is that the attacker negotiates TLS with the >> server and then subsequently proxies the client's negotiation *over* >> that channel. This allows the attacker to inject arbitrary content of >> their choice in front of data sent from the TLS client to the TLS >> server. This data will be treated by the server as if it came from the >> client. Once the new handshake has finished, the attacker can't >> do anything else useful. > > I'll become a bit pedantic and note here that this isn't really a TLS > issue. We have an initial server-authenticated only session and some > renegotiation of parameters over it to authenticate the client. However > TLS doesn't guarantee[0] that if the renegotiation is successful > authenticating the client, then the data from the initial session were > also by the same authenticated client. > Think for example a session that it is anonymous (DH). Why one should > assume that commands over the anonymous connection are to be trusted if > a successful renegotiation follows? > > So for me the issue is on HTTP's usage of the TLS protocol > renegotiation. After a TLS renegotiation for authentication the previous > command cache should have been cleared and reissued after negotiation. I think you have a point, I'm not sure if it's HTTP as such that is to blame, rather the assumptions made by the frameworks implementing it. Authentication via client-certificate in HTTPS has always been a bit at odds with the rest of the HTTP authentications schemes. HTTP has status codes for requiring authentication (401), but client-cert authentication doesn't fit well into this model. The need vs. want client-cert feature itself isn't handled particularly well by browsers. Requiring a client-cert (and closing the connection if one isn't presented) can be confusing to the user. I think the problem comes from the fact that SSL/TLS is intended to behave transparently, like normal sockets, for the application using it, whereas this issue is clearly not the case when re-negotiation happens. Perhaps this should just be another special case handled by the application layer (the other special case I have in mind is the way closing the socket behaves slightly differently to normal sockets). This attack could be prevented if the HTTP framework was notified when a renegotiation had happened and thus made aware that the command it just got may not have been made with the same credentials. For example, this wouldn't be an issue if: - the HTTP method sent just before the renegotiation was a safe method (GET/HEAD) - the HTTP application was using safe methods correctly (no GET /page?action=delete for example) - if the HTTP method isn't safe (POST, PUT, ...), then send a 401 status response. The problem here is that a 401 response status requires a challenge header according to the HTTP spec and there isn't one to require a client certificate; this being said, it should be possible to extend HTTP and have 'WWW-Authenticate: Transport' (or something similar) meaning that it's up to TLS to provide the required authentication information. As you said, I also think handling this problem at the TLS level is cleaner since the assumption that TLS sockets behave transparently like normal sockets should still be valid in this case. Best wishes, Bruno. From uri@ll.mit.edu Fri Nov 6 08:00:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5513A69B8 for ; Fri, 6 Nov 2009 08:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMRYgizxi3kn for ; Fri, 6 Nov 2009 08:00:27 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id E6B8F3A6359 for ; Fri, 6 Nov 2009 08:00:26 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nA6G0gEJ010773; Fri, 6 Nov 2009 11:00:42 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAhua4KK; Fri Nov 6 10:23:38 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Fri, 6 Nov 2009 10:23:38 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: Nicolas Williams , Marsh Ray Date: Fri, 6 Nov 2009 10:23:35 -0500 Thread-Topic: [TLS] TLS renegotiation issue Thread-Index: Acpeal0YLjVuNje/RNeyNT5lbOFT0AAir4d1 Message-ID: In-Reply-To: <20091105223130.GN1105@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:00:28 -0000 There's an example of using such abstract API in SNMPv3. Where it was also debated ("IETF doesn't do API" :-), but the common sense prevailed. On 11/5/09 17:31 , "Nicolas Williams" wrote: > On Thu, Nov 05, 2009 at 04:28:57PM -0600, Marsh Ray wrote: >> Nicolas Williams wrote: >>> I don't think it was ever really true that "the IETF doesn't do APIs". >>=20 >> I would add here that if the IETF had compared the way TLS looks on the >> wire with how it is presented by SSL APIs in practice, this defect could >> not have gone unnoticed. >=20 > Indeed. Larry Zhu described to me how the SSPI models TLS just a few > days ago. I should have noticed immediately the lack of binding, but > because I wasn't also thinking of HTTPS, I didn't. >=20 > I'd go far enough to say that we must consider at least abstract APIs to > protocols such as TLS. >=20 > Nico --=20 Regards, Uri uri@ll.mit.edu From stpeter@stpeter.im Fri Nov 6 08:58:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F94C3A6907 for ; Fri, 6 Nov 2009 08:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=1.905, 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 U1KehT8yNuj7 for ; Fri, 6 Nov 2009 08:58:49 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 683083A6976 for ; Fri, 6 Nov 2009 08:58:49 -0800 (PST) Received: from squire.local (dsl-175-187.dynamic-dsl.frii.net [216.17.175.187]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5BFB240D09; Fri, 6 Nov 2009 09:59:12 -0700 (MST) Message-ID: <4AF455DF.5040106@stpeter.im> Date: Fri, 06 Nov 2009 09:59:11 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> In-Reply-To: <4AF33D07.7040100@gnutls.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , "tls@ietf.org" Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:58:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/5/09 2:00 PM, Nikos Mavrogiannopoulos wrote: > Eric Rescorla wrote: >> TLS WG members will want to check out this announcement of a >> new attack on the TLS renegotiation logic. See here: >> >> http://www.extendedsubset.com/ >> >> The high-level summary is that the attacker negotiates TLS with the >> server and then subsequently proxies the client's negotiation *over* >> that channel. This allows the attacker to inject arbitrary content of >> their choice in front of data sent from the TLS client to the TLS >> server. This data will be treated by the server as if it came from the >> client. Once the new handshake has finished, the attacker can't >> do anything else useful. > > I'll become a bit pedantic and note here that this isn't really a TLS > issue. We have an initial server-authenticated only session and some > renegotiation of parameters over it to authenticate the client. However > TLS doesn't guarantee[0] that if the renegotiation is successful > authenticating the client, then the data from the initial session were > also by the same authenticated client. > Think for example a session that it is anonymous (DH). Why one should > assume that commands over the anonymous connection are to be trusted if > a successful renegotiation follows? > > So for me the issue is on HTTP's usage of the TLS protocol > renegotiation. After a TLS renegotiation for authentication the previous > command cache should have been cleared and reissued after negotiation. I tend to agree. Some folks in the XMPP community have analyzed the use of TLS in XMPP, and their preliminary conclusion is that XMPP is not vulnerable to this attack because the client and server are required to clear the security context and restart the XML stream after TLS negotiation (or renegotiation). Those who did this analysis will publish a brief report about their findings in the near future. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr0Vd8ACgkQNL8k5A2w/vyeqQCgpzZakXwr62UdxAHdNyqwe4xe WEUAoMPGdY94w+/+oAv9oYC0I9iu7hnI =sjVM -----END PGP SIGNATURE----- From mrex@sap.com Fri Nov 6 09:13:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1759528C179 for ; Fri, 6 Nov 2009 09:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.192, 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 1aSj1cHBltK2 for ; Fri, 6 Nov 2009 09:13:24 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A4FC028C177 for ; Fri, 6 Nov 2009 09:13:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA6HDjT3020102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 18:13:45 +0100 (MET) From: Martin Rex Message-Id: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp> To: Bruno.Harbulot@manchester.ac.uk (Bruno Harbulot) Date: Fri, 6 Nov 2009 18:13:44 +0100 (MET) In-Reply-To: <4AF444EE.9070401@manchester.ac.uk> from "Bruno Harbulot" at Nov 6, 9 03:46:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:13:25 -0000 Bruno Harbulot wrote: > > > > > So for me the issue is on HTTP's usage of the TLS protocol > > renegotiation. After a TLS renegotiation for authentication the previous > > command cache should have been cleared and reissued after negotiation. > > I think you have a point, I'm not sure if it's HTTP as such that is to > blame, rather the assumptions made by the frameworks implementing it. The ramification are amplificated by the HTTP 1.1 Connection:keep-alive that allows pipelining of requests and results in asynchronous processing of requests and replys. For re-negotiations, the following requirement from rfc5246 6.2.1. Fragmentation (last paragraph): Note: Data of different TLS record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. Provides and interesting additional challenge, and documents that at least some of the original protocol designers didn't sufficiently reflect on the implications. Similarly rfc-5246, 7.4.1.1. Hello Request Since handshake messages are intended to have transmission precedence over application data, it is expected that the negotiation will begin before no more than a few records are received from the client. If the server sends a HelloRequest but does not receive a ClientHello in response, it may close the connection with a fatal alert. I think it is underspecified what "interleaved application data and handshake messages" and "handshake message have transmission precedence over application data" is supposed to mean, and what kind of signalling would be necessary between the TLS protocol stack and the application caller in order to convey the underspecified semantics unambiguously. I wasn't remotely aware of the applicability for real world scenarios beyond the command execution I suggested in my description, when I wrote about an MITM attack scenario that had briefly crossed my mind the night before, and for which I had not found any indications in rfc5246 (scanning it for about 20 minutes) that would stop it, before sending off the mail. I had not realized that one could similarly proxy an initial TLS handshake with a client into a renegotiate of the server and things like the request-completion for the basic-auth based or cookie-based authentications. Marshs published research on the issue expanded my thinking about susceptible scenarios significantly. Excellent work, Marsh! -- and thank you for all the research! For the cookie-auth or basic-auth based scenarios depicted by Marsh, the asynchronous processing of pipelined requests creates interesting new opportunities. "Clearing the command cache" might require a significant change in some application protocol stacks. In order to efficientl process requests, and nowadays Connection: keep-alive pipelined requests, there are often intermediate layers for the request parsing that will combine and re-slice what comes out of SSL, so that the application may efficiently process the requests--including URL argument parsing, parsing the MIME-header, parsing certain header fields (Host:,Cookie:,authorization) and potentially code page translations/transformations. When analyzing performance problems reported by a customer 3 years ago I noticed that their Apache reverse proxy (using SSL-reencryption into our backend software) was tearing up the forwarded requests into pieces, forwarding each line of the MIME-header of the request and the empty newline into seperate SSL-records -- slowing down the processing of the request significantly. >From the original design, and in the two quoted paragraphs above, it appears that SSL and its successor TLS was intended to be _very_ transparent, and the spec contains guidance for security-relevant signaling to the application only for the initial TLS handshake on a connection (full initial handshake, and session resume), but _NOT_ for the session renegotiation. Therefore, I think, we do have a real shortcoming of the SSL/TLS protocol, and we really should scramble to fix it. That includes improving on the guidance for the signaling and semantics of a TLS session renegotiate of the TLS protocol stack to the application -- in a fashion so that it can be folded back into rfc5246bis. -Martin From Nicolas.Williams@sun.com Fri Nov 6 09:42:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38573A67EA for ; Fri, 6 Nov 2009 09:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 eU6gc006Zin9 for ; Fri, 6 Nov 2009 09:42:02 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 147373A6768 for ; Fri, 6 Nov 2009 09:42:01 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA6HgPDY002513 for ; Fri, 6 Nov 2009 17:42:25 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 nA6HgOCi025889 for ; Fri, 6 Nov 2009 10:42:25 -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 nA6HNOWL010198; Fri, 6 Nov 2009 11:23:24 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6HNN85010197; Fri, 6 Nov 2009 11:23:23 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Nov 2009 11:23:23 -0600 From: Nicolas Williams To: Nikos Mavrogiannopoulos Message-ID: <20091106172323.GY1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF33D07.7040100@gnutls.org> User-Agent: Mutt/1.5.7i Cc: Eric Rescorla , "tls@ietf.org" Subject: Re: [TLS] TLS or HTTP issue? (was: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:42:02 -0000 This vulnerability will affect different application protocols differently. It certainly affects HTTP. I think LDAP may not be susceptible, but I'm not sure; I'm even less sure about IMAP. Others have indicated that there definitely exist other applications besides HTTP which do suffer from this vulnerability though, and that's the key: of course there may be more than one application protocol that is made vulnerable by this TLS problem. We must fix this problem in TLS itself. The fix may require changes to some applications, depending not so much on the protocol as on the TLS API used. Nico -- From nwf@cs.jhu.edu Fri Nov 6 09:49:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C6C3A68E8 for ; Fri, 6 Nov 2009 09:49:07 -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 xLlVvrjT2xo5 for ; Fri, 6 Nov 2009 09:49:06 -0800 (PST) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) by core3.amsl.com (Postfix) with ESMTP id 150133A68F7 for ; Fri, 6 Nov 2009 09:49:06 -0800 (PST) Received: from gradx.cs.jhu.edu (gradx.cs.jhu.edu [128.220.13.52]) by blaze.cs.jhu.edu (8.14.3/8.14.3) with ESMTP id nA6HnPpR018685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Nov 2009 12:49:25 -0500 (EST) Received: from gradx.cs.jhu.edu (localhost.localdomain [127.0.0.1]) by gradx.cs.jhu.edu (8.14.2/8.13.1) with ESMTP id nA6HnPEX012225; Fri, 6 Nov 2009 12:49:25 -0500 Received: (from nwf@localhost) by gradx.cs.jhu.edu (8.14.2/8.13.8/Submit) id nA6HnO2f012224; Fri, 6 Nov 2009 12:49:24 -0500 Date: Fri, 6 Nov 2009 12:49:24 -0500 From: Nathaniel W Filardo To: Nicolas Williams Message-ID: <20091106174924.GL19125@gradx.cs.jhu.edu> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> <20091106172323.GY1105@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8rALO501tkk3VWH" Content-Disposition: inline In-Reply-To: <20091106172323.GY1105@Sun.COM> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Eric Rescorla , "tls@ietf.org" Subject: Re: [TLS] TLS or HTTP issue? (was: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:49:07 -0000 --n8rALO501tkk3VWH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 06, 2009 at 11:23:23AM -0600, Nicolas Williams wrote: > This vulnerability will affect different application protocols > differently. It certainly affects HTTP. I think LDAP may not be > susceptible, but I'm not sure; I'm even less sure about IMAP. Others > have indicated that there definitely exist other applications besides > HTTP which do suffer from this vulnerability though, and that's the key: > of course there may be more than one application protocol that is made > vulnerable by this TLS problem. >=20 > We must fix this problem in TLS itself. The fix may require changes to > some applications, depending not so much on the protocol as on the TLS > API used. >=20 > Nico Forgive me if I'm mistaken, but as far as I understand (one of) the attack(s), it relies on an application protocol (e.g. HTTP) request being 'fragmented' across the renegotiation (thus the need for, in HTTP, the attacker-provided X-Swallow-This: header to absorb the client's GET)... Is it in general sufficient for the server to initiate the reauthentication only in response to a complete request? Alternatively, in the case of HTTP, is it sufficient to reject requests with client-provided headers (i.e. anything except the GET/POST/... line) on the outer connection? That is, are there any clients which actually depend on being able to fragment requests like this? Just curious. Thanks. --nwf; --n8rALO501tkk3VWH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkr0YaQACgkQTeQabvr9Tc+9qwCaAuXQII5L6lQ6LRTa1sD9DWkW DWEAn2YzmgMMqRmamh4eVac714bztgnx =myGp -----END PGP SIGNATURE----- --n8rALO501tkk3VWH-- From marsh@extendedsubset.com Fri Nov 6 10:02:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80C13A6944 for ; Fri, 6 Nov 2009 10:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 ASlKuBZR5NQt for ; Fri, 6 Nov 2009 10:02:30 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 50B5A3A68F5 for ; Fri, 6 Nov 2009 10:02:30 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6T9B-0002GQ-It for tls@ietf.org; Fri, 06 Nov 2009 18:02:53 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9553B667B for ; Fri, 6 Nov 2009 18:02:52 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX180QPzzGy1cqTK4tE/5hRhFFFYiBQL0ZUM= Message-ID: <4AF464CC.7000800@extendedsubset.com> Date: Fri, 06 Nov 2009 12:02:52 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> <20091106172323.GY1105@Sun.COM> <20091106174924.GL19125@gradx.cs.jhu.edu> In-Reply-To: <20091106174924.GL19125@gradx.cs.jhu.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 18:02:32 -0000 Nathaniel W Filardo wrote: > Forgive me if I'm mistaken, but as far as I understand (one of) the > attack(s), it relies on an application protocol (e.g. HTTP) request being > 'fragmented' across the renegotiation (thus the need for, in HTTP, the > attacker-provided X-Swallow-This: header to absorb the client's GET)... I expect there will be others (far more skilled than I in the art of HTTP abuse) improving on that in the coming days. Steve and I just developed a few examples to demonstrate the severity of the problem. This capability has been characterized as a "blind plaintext prefix injection attack". I don't think many protocols have been designed to be resilient against that kind of thing, those that are not vulnerable are that way by accident. HTTP is particularly susceptible, but I'm sure many more protocols will be found to be exploitable. - Marsh From Nicolas.Williams@sun.com Fri Nov 6 11:25:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A2928C116 for ; Fri, 6 Nov 2009 11:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 MZoSHlTrGm4L for ; Fri, 6 Nov 2009 11:25:11 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3CE5B3A62C1 for ; Fri, 6 Nov 2009 11:25:10 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA6JPWDo021829 for ; Fri, 6 Nov 2009 19:25:33 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 nA6JPViq034660 for ; Fri, 6 Nov 2009 12:25:32 -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 nA6Ix0Qa010243; Fri, 6 Nov 2009 12:59:00 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6Ix0Bd010242; Fri, 6 Nov 2009 12:59:00 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Nov 2009 12:59:00 -0600 From: Nicolas Williams To: Nathaniel W Filardo Message-ID: <20091106185859.GA1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> <20091106172323.GY1105@Sun.COM> <20091106174924.GL19125@gradx.cs.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091106174924.GL19125@gradx.cs.jhu.edu> User-Agent: Mutt/1.5.7i Cc: Eric Rescorla , "tls@ietf.org" Subject: Re: [TLS] TLS or HTTP issue? (was: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:25:12 -0000 On Fri, Nov 06, 2009 at 12:49:24PM -0500, Nathaniel W Filardo wrote: > Forgive me if I'm mistaken, but as far as I understand (one of) the > attack(s), it relies on an application protocol (e.g. HTTP) request being > 'fragmented' across the renegotiation (thus the need for, in HTTP, the > attacker-provided X-Swallow-This: header to absorb the client's GET)... Sortof. The problem is not that the application protocol _explicitly_ allows TLS re-negotiation in the middle of an application protocol message. I bet HTTP has nothing whatsoever to say about that. The fact that HTTP does allow that folows from the fact that the application protocol is layered atop TLS. (I.e., this isn't about HTTP's/HTTPS' authors being bloody stupid. Lots of very smart people have been working in these fields without having noticed this problem.) > Is it in general sufficient for the server to initiate the reauthentication > only in response to a complete request? Alternatively, in the case of HTTP, Necessary, but not sufficient. You must also drop all prior context. Alternatively you must bind the new TLS connection to the old, exactly the proposed fix. (Note that the proposed fix is even more independent of application protocol design than the flaw.) > is it sufficient to reject requests with client-provided headers (i.e. > anything except the GET/POST/... line) on the outer connection? That is, > are there any clients which actually depend on being able to fragment > requests like this? The problem is that the HTTP implementation may have no knowledge of what's going on at the TLS layer[*]. Yes, the HTTP implementation can tell the TLS layer to re-negotiate, and it can find out what the user's cert was afterwards. But if the client initiates [re-]negotiation, the HTTP server may have no idea that this is happening. Worse, the TLS protocol doesn't have any bits on the wire saying that "this is a re-negotiation", so the client may merely be initiating the first negotiation even though to the server that looks like a re-negotiation. In an application protocol with a "starttls" style approach to TLS, this unawareness of what's going on in the TLS layer can exist, even if it seems inutitively less likely, but at least such an application protocol can be constructed so that application messages that can fit in a TLS record are never fragmented across TLS [re-]negotiations. Not that that's enough (see above). [*] Look at it from a developer's point of view: the TLS API may look very similar to read(2) and write(2) system calls. Applications are not normally aware of which reads and writes result in disk I/O (or TCP segments, or IP packets, or whatever). The situation with respect to TLS can be quite similar, though just how similar will depend on each specific TLS API. Nico -- From mrex@sap.com Fri Nov 6 11:27:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F65328C0D8 for ; Fri, 6 Nov 2009 11:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.177, 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 e0VWlOd0Vnal for ; Fri, 6 Nov 2009 11:27:46 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6831928C1C0 for ; Fri, 6 Nov 2009 11:27:45 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA6JS7Pr029523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 20:28:07 +0100 (MET) From: Martin Rex Message-Id: <200911061928.nA6JS7vq000076@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Fri, 6 Nov 2009 20:28:07 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Nov 5, 9 10:52:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:27:47 -0000 Eric Rescorla wrote: > > > 4.1 Client Considerations > > > > Essentially we are going to hold TLS clients and the installed > > base of good Servers responsible for the broken Servers out there. > > That feels very wrong. > > I'm not recommending that clients do that. What I'm trying to say is that > *if* a client wants to be totally sure then all it can do is require > the extension. > I agree it's impractical (and probably unwise) to suggest that they actually > behave that way. > > Do you agree that the characterization above is correct? If so, how can I > update the draft to make that clearer? Yes, unfortunately, the description is the honest and cold truth. It's challenging to come up with something better. Maybe the consequences of the suggestion to no longer talk to SSL/TLS servers without that extension should be made more explicit. As correctly described in Marshs publication, the problem affects all existing releases of the SSL and TLS protocol family. I assume that this WG, the IETF, the vendors and the consumers would appreciate if the fix could be applied to the entire installed base, no matter what protocol level each component implements. It's not always an option to move to a newer implementation that also supports a more recent version of TLS, so I would appreciate that we describe two additional things in this draft: - to describe how to add/implement this fix to each and every affected protocol version of the SSL/TLS Family. I just noticed that SSLv3 does _NOT_ have a "no_renegotiate" alert! To me, it looks like the SSLv3 spec does not specify how to deny performing a renegotiate. Which is slightly odd, since there are SSLv3 implementations that do not implement renegotiation... - to describe/suggest the behaviour for implementations of SSL/TLS that do not support (or do not want to perform) renegotiation, in particular for SSLv3. - since we currently overload the empty extension with signaling to different things: - I am a patched server - I support secure renegotiation we should probably explicitly describe what a TLS v1.x Server should do if it does not implement TLS renego in the server or reliably know that it will not perform renegotiation. Since it is against common sense that such a server responds with a TLS Extension "I support secure renegotiation" in the ServerHello, we should explicity write what we want them to implement. -Martin From mike-list@pobox.com Fri Nov 6 11:53:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D2628C12E for ; Fri, 6 Nov 2009 11:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb6xqJyoS5Q1 for ; Fri, 6 Nov 2009 11:53:52 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id ADA8A3A683A for ; Fri, 6 Nov 2009 11:53:52 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0968B95D58 for ; Fri, 6 Nov 2009 14:54:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=sbQL+iEW2171 hnkQrkbES0ArheY=; b=mLSQKKDwV9CfYjjz8X8PkRDEIbD4BD2IzJ0rrrebyyEQ Mgv3YxF1Rx4TEulPo9REEGMgguIXMhrFIdD1NOzxOvVM+kudSfJj/exnoIk5J4ZA ptoE4fF9mYd+nfapOI7dy3BBx6q8q6crGdk5mXg9zSU1OZzIeiNKZMpwkqhbrnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=RJRH5S 69bvd/hf3f2vIeF+uW/IWVhOHquZrbh4GVwRTlsbhhjBHPetCRUBfKErWBg9S1mV VCwhX05q4BFNIvBMJngr4cttkiGllEzFdAB8EXky8WWE3UZv6ooJ5O+HCuPIP/Lc WHvuN1v+xgBe2L8kKIhT0wKN5RoRm0029cxZQ= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 05C3795D57 for ; Fri, 6 Nov 2009 14:54:16 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 80FDA95D54 for ; Fri, 6 Nov 2009 14:54:15 -0500 (EST) Message-ID: <4AF47F1A.6080502@pobox.com> Date: Fri, 06 Nov 2009 11:55:06 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911061928.nA6JS7vq000076@fs4113.wdf.sap.corp> In-Reply-To: <200911061928.nA6JS7vq000076@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 29D982DE-CB0E-11DE-B74D-D595BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:53:53 -0000 > I assume that this WG, the IETF, the vendors and the consumers would > appreciate if the fix could be applied to the entire installed base, > no matter what protocol level each component implements. > > It's not always an option to move to a newer implementation that > also supports a more recent version of TLS, so I would appreciate > that we describe two additional things in this draft: > > - to describe how to add/implement this fix to each and > every affected protocol version of the SSL/TLS Family. > > I just noticed that SSLv3 does _NOT_ have a "no_renegotiate" alert! > To me, it looks like the SSLv3 spec does not specify how to > deny performing a renegotiate. Which is slightly odd, since > there are SSLv3 implementations that do not implement renegotiation... Even more importantly, SSLv3 does not support extensions. Mike > - to describe/suggest the behaviour for implementations of SSL/TLS > that do not support (or do not want to perform) renegotiation, > in particular for SSLv3. > > - since we currently overload the empty extension with signaling > to different things: > - I am a patched server > - I support secure renegotiation > > we should probably explicitly describe what a TLS v1.x Server > should do if it does not implement TLS renego in the server or > reliably know that it will not perform renegotiation. > Since it is against common sense that such a server responds > with a TLS Extension "I support secure renegotiation" in > the ServerHello, we should explicity write what we want them > to implement. > > > -Martin From mrex@sap.com Fri Nov 6 11:56:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B223A6859 for ; Fri, 6 Nov 2009 11:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.164, 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 dFk6QwuBjYfA for ; Fri, 6 Nov 2009 11:56:31 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 923103A67B6 for ; Fri, 6 Nov 2009 11:56:31 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA6Jurvp019407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 20:56:53 +0100 (MET) From: Martin Rex Message-Id: <200911061956.nA6JuqtB001719@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 6 Nov 2009 20:56:52 +0100 (MET) In-Reply-To: <200911061928.nA6JS7vq000076@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 6, 9 08:28:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:56:33 -0000 Martin Rex wrote: > > It's not always an option to move to a newer implementation that > also supports a more recent version of TLS, so I would appreciate > that we describe two additional things in this draft: While the things just described do not (necessarily) change the proposed wire-protocol, they might change semantics and interoperability of the protocol exchange with ongoing implementations. Making handshakes with attackers fail earlier during the handshake is not my concern, of course. But aside from this proposal, I was never really happy with the performance impact of the delayed client auth, because a TLS renegotiation alwas incurs a full TLS handshake. There used to be (I have not checked lately) a particularly bad user experience when connecting a firefox (2.x) to MS IIS6 on W2K3 configured in directory-level access permissions (i.e. the configuration that results in delayed TLS client auth through renegotiation). When MS IIS6 was configured to allow client-cert based authentication plus HTTP-authenticate:Negotiate or basic-auth, but the firefox browser did not have a client cert (or the user did not want to send it), then the bug in the MS IIS6 server-side session cache resulted in a renegotiation on every new connection, which resulted in a certificate selection popup. This could result in several popups per page if you were browsing regular web-pages in protected areas rather than plain directories. What I would have appreciated, and what could prevent this nonsense, is an extension that signals from the client to the server "You do not need to try a CertificateRequest on me, I will not send you a certificate!". If a browsers memorizes the uses decision (to not send a cert, or that there is no cert), then it would really help if it could tell this to the SSL/TLS server right away, instead of requiring the server to wonder and probe this information with a full blown TLS handshake through TLS renegotiate. I do _not_ want to get any improvement in this area get into the way of fixing the "secure renegotiation" issue. Well only if the implementors/vendors that are most affected by the security problem propose/agree that we could add such signalling here (plus TLS WG consensus, of course). -Martin From mrex@sap.com Fri Nov 6 11:59:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51E53A69EF for ; Fri, 6 Nov 2009 11:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.153, 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 Y1IOH1DDPDtl for ; Fri, 6 Nov 2009 11:59:28 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id F05513A67B6 for ; Fri, 6 Nov 2009 11:59:27 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA6JxnLB017351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 20:59:49 +0100 (MET) From: Martin Rex Message-Id: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 6 Nov 2009 20:59:49 +0100 (MET) In-Reply-To: <4AF47F1A.6080502@pobox.com> from "Michael D'Errico" at Nov 6, 9 11:55:06 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:59:29 -0000 Michael D'Errico wrote: > > > - to describe how to add/implement this fix to each and > > every affected protocol version of the SSL/TLS Family. > > > > I just noticed that SSLv3 does _NOT_ have a "no_renegotiate" alert! > > To me, it looks like the SSLv3 spec does not specify how to > > deny performing a renegotiate. Which is slightly odd, since > > there are SSLv3 implementations that do not implement renegotiation... > > Even more importantly, SSLv3 does not support extensions. You're correct. SSLv3 allows extensions in the ClientHello that are to be ignored, but it does not support them in ServerHello. Oooops. Suggestions? -Martin From Nicolas.Williams@sun.com Fri Nov 6 12:14:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C493A69E2 for ; Fri, 6 Nov 2009 12:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 hiL7Q75wN2sH for ; Fri, 6 Nov 2009 12:14:45 -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 66CD23A680B for ; Fri, 6 Nov 2009 12:14:41 -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 nA6KF5DT021154 for ; Fri, 6 Nov 2009 20:15:05 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 nA6KF5Ui001912 for ; Fri, 6 Nov 2009 13:15:05 -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 nA6K3YFu010291; Fri, 6 Nov 2009 14:03:34 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6K3YBs010290; Fri, 6 Nov 2009 14:03:34 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Nov 2009 14:03:34 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091106200333.GE1105@Sun.COM> References: <4AF47F1A.6080502@pobox.com> <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 20:14:52 -0000 On Fri, Nov 06, 2009 at 08:59:49PM +0100, Martin Rex wrote: > Michael D'Errico wrote: > > > > > - to describe how to add/implement this fix to each and > > > every affected protocol version of the SSL/TLS Family. > > > > > > I just noticed that SSLv3 does _NOT_ have a "no_renegotiate" alert! > > > To me, it looks like the SSLv3 spec does not specify how to > > > deny performing a renegotiate. Which is slightly odd, since > > > there are SSLv3 implementations that do not implement renegotiation... > > > > Even more importantly, SSLv3 does not support extensions. > > You're correct. SSLv3 allows extensions in the ClientHello that > are to be ignored, but it does not support them in ServerHello. > > Oooops. > > Suggestions? Stop using SSLv3. Its end has arrived. From Nicolas.Williams@sun.com Fri Nov 6 12:20:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39623A6AA5 for ; Fri, 6 Nov 2009 12:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, 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 v+tP6934HlnL for ; Fri, 6 Nov 2009 12:20:46 -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 8B8BF3A6AA4 for ; Fri, 6 Nov 2009 12:20:46 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA6KL9fC007952 for ; Fri, 6 Nov 2009 20:21:09 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 nA6KL9ZT006086 for ; Fri, 6 Nov 2009 13:21:09 -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 nA6Jl9c2010273; Fri, 6 Nov 2009 13:47:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6Jl9jW010272; Fri, 6 Nov 2009 13:47:09 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Nov 2009 13:47:09 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091106194708.GC1105@Sun.COM> References: <200911060105.nA615jen027166@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911060105.nA615jen027166@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 20:20:47 -0000 On Fri, Nov 06, 2009 at 02:05:45AM +0100, Martin Rex wrote: > Michael Gray wrote: > > > > Eric Rescorla wrote: > > > http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html > > > > IMHO The proposed fix looks to be also introducing the concept of > > Retrospective Trust into TLS. This being necessary due to the problem > > highlighted in the HTTP protocol in that it will process messages that > > arrived prior to authentication etc. What is "Retrospective Trust"? A search for that finds unrelated items. A search for "Retrospective Trust security" finds restrospectives on workshops and what not. In any case, assuming that you mean that authenticating something said earlier is bad, I disagree, provided that one actually does that (as opposed, as in the case of this bug, merely thinking that one is authenticating something already said but not really). There are, in fact, a number of places in our protocols where we authenticate something said earlier. In many of those cases we have no choice but to do that! Consider TLS, SSHv2, IKv2, etcetera. They all start with an unprotected negotiation and key exchange, followed by an exchange of messages that authenticates the unprotected negotiation using the exchanged keys. That's a matter of bootstrapping security, yes, but that happens often. > To some degree I share your concern. > > However, I do believe that the the proposed fix to provide secure > renegotiation primarily fixes a problem in the TLS protocol, which > does not live up to its own promises on security of a TLS session > renegotiation. > > Admittedly, the momentum behind this effort is the prospective > blessing this will provide on the current awful practice in this > area, because first of all, vendors _and_ implementors are trying > to maintain the current level of look&feel / usability -- or maybe > we should call it "convenience". > > If we forgive the applications today, they are going to do even > more daring things tomorrow -- and that could be things that > we cannot fix easily. I don't think what the apps do, particularly HTTP, is bad at all. What's bad is the lack of binding between the disparate TLS connections that result. What's so bad about deferring authentication of the user until after you know that it's needed? Nothing, _provided that_ you also ensure that the request that required authentication came from the same entity that you subsequently authenticated. I think it's fair to say that folks using TLS expected the binding, which we now know wasn't there, to be there -- or at least that they intuitively expected such a binding, even if the explicit thought of it never entered their consciousness. They use a security tool, and as far as they knew they used it correctly. It is not their fault, but ours, that we did not document the lack of this binding, or that we didn't provide it to begin with (I'm using the royal we; I'm not to blame! :) > In real life, however, security is much more about risk management > than absolute security. Bruce Schneier has written at least a dozen > good articles about that topic. The more difficult security is to > use, the more often people will work around it. What's the relevance of that here? IIUC, you think delaying authentication was purely for convenience, and that convenience is the mother of all security bugs -- that convenience is almost a sin. Right? But if so, I don't agree. Security features have to be convenient in order to stand a chance of being used properly or at all. That doesn't mean that we should accept convenience over security, but that where we can get both, we should. > I think we should improve on guidance, rather than be totally anal > about who goofed which part. In this case we need to improve the design, not the guidance. Granted, we could choose to not improve the design and rely only on guidance. However, it's much better to make the problem just go away. Nico -- From marsh@extendedsubset.com Fri Nov 6 12:54:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D6F3A6893 for ; Fri, 6 Nov 2009 12:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 wMTf6tOEzeNN for ; Fri, 6 Nov 2009 12:54:28 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 723693A6859 for ; Fri, 6 Nov 2009 12:54:28 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6Vpb-000OYf-Pf for tls@ietf.org; Fri, 06 Nov 2009 20:54:51 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C3C20667B for ; Fri, 6 Nov 2009 20:54:50 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/l8kVynrHG/ZnJw1cxjWoACFlBeHxF7ok= Message-ID: <4AF48D1A.4070708@extendedsubset.com> Date: Fri, 06 Nov 2009 14:54:50 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911060105.nA615jen027166@fs4113.wdf.sap.corp> <20091106194708.GC1105@Sun.COM> In-Reply-To: <20091106194708.GC1105@Sun.COM> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 20:54:29 -0000 Nicolas Williams wrote: > What is "Retrospective Trust"? A search for that finds unrelated items. > A search for "Retrospective Trust security" finds restrospectives on > workshops and what not. I think the term "retroactive authentication" is a bit better to describe what HTTPS servers does for dynamic client certs. > In any case, assuming that you mean that authenticating something said > earlier is bad, I disagree, provided that one actually does that (as > opposed, as in the case of this bug, merely thinking that one is > authenticating something already said but not really). > > There are, in fact, a number of places in our protocols where we > authenticate something said earlier. In many of those cases we have no > choice but to do that! Consider TLS, SSHv2, IKv2, etcetera. They all > start with an unprotected negotiation and key exchange, followed by an > exchange of messages that authenticates the unprotected negotiation > using the exchanged keys. That's a matter of bootstrapping security, > yes, but that happens often. My feeling is that it is extra-tricky to get right, and any mistakes seem to default to resulting in a security vulnerability. Seeing this in some webserver code was one of the things that originally led me to the problem. However, I do not agree that the concept is fundamentally broken. After all, signing a document at the bottom of a page is not worse than signing it at the top. What you have to worry about is the possibility that your signature on the last page may not cover all the pages in a multi-page document. All the attacker may need in that case is a staple remover. > I don't think what the apps do, particularly HTTP, is bad at all. > What's bad is the lack of binding between the disparate TLS connections > that result. > > What's so bad about deferring authentication of the user until after you > know that it's needed? Nothing, _provided that_ you also ensure that > the request that required authentication came from the same entity that > you subsequently authenticated. That is a good point I think. Even though the first session had an "anonymous" level of authentication, that doesn't mean that the subsequent authenticated session didn't need to authenticate the original request! In this case, the client of that first anonymous session is implicitly assigned an identity, but is not authenticated properly. He needs to be authenticated as being "the same party as the client in this other session". > I think it's fair to say that folks using TLS expected the binding, > which we now know wasn't there, to be there -- or at least that they > intuitively expected such a binding, even if the explicit thought of it > never entered their consciousness. The "binding" was effectively there in SSLv2 because it was guaranteed that there was only one session. The SSLv3 spec quietly introduced the concept of renegotiation and multiple sessions without ever addressing the fact that this would translate into security vulnerabilities unless every existing application changed its internal model for handling SSL connections. - Marsh From rrelyea@redhat.com Fri Nov 6 13:39:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8CD3A67EC for ; Fri, 6 Nov 2009 13:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 dDXtu7whLF1e for ; Fri, 6 Nov 2009 13:39:59 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 298C53A67AF for ; Fri, 6 Nov 2009 13:39:59 -0800 (PST) Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nA6LeM0i017988; Fri, 6 Nov 2009 16:40:22 -0500 Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nA6LeLiN027216; Fri, 6 Nov 2009 16:40:22 -0500 Message-ID: <4AF497C5.5060801@REDHAT.COM> Date: Fri, 06 Nov 2009 13:40:21 -0800 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: mrex@sap.com References: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> In-Reply-To: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.97a Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020002070805020709060702" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.18 Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 21:40:00 -0000 This is a cryptographically signed message in MIME format. --------------ms020002070805020709060702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/06/2009 11:59 AM, Martin Rex wrote: > Michael D'Errico wrote: > =20 >> =20 >>> - to describe how to add/implement this fix to each and >>> every affected protocol version of the SSL/TLS Family. >>> >>> I just noticed that SSLv3 does _NOT_ have a "no_renegotiate" ale= rt! >>> To me, it looks like the SSLv3 spec does not specify how to >>> deny performing a renegotiate. Which is slightly odd, since >>> there are SSLv3 implementations that do not implement renegotiat= ion... >>> =20 >> Even more importantly, SSLv3 does not support extensions. >> =20 > You're correct. SSLv3 allows extensions in the ClientHello that > are to be ignored, but it does not support them in ServerHello. > =20 In practice, there are too many servers that blow up even on extensions in clientHellos. So many that NSS only uses extensions in TLS, not in SSL= 3. There are some servers that claim to be TLS, that also fail to accept extensions. To date we have treated those as TLS intolerant SSL 3.0 servers, since it's clearly incorrect behavior for a TLS server to just barf on an extension. > Oooops. > > Suggestions? > =20 For us, this means SSL3 would be dead in the case you require the extensi= on. bob > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > =20 --------------ms020002070805020709060702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV7DCC Bv8wggXnoAMCAQICAwCrKTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MTAxNDAwMDAwMVoXDTEwMTAxNDIwNTQyMVowbjEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9dBmw8V94Rx84iwE5RpiO+uHKS5e91CHnKf JsbEOzPxS7Hgizt78ratBbhkudQ7bJIH1o9nh0Q5c/LdOlWUF1Jn+3+JNGvs6h/vlmfCYGPK TZpUbwPm8Rmik+bDNlAOUkDieZHfUg8HOdGrqvp1prqqwLMzgovi5YiETf28SO9kxNqjkbBL VxsBlHrnjG1dmn8jAYZ1XPctXMEsHV+2EISDOPYWl/CE2jt7km6Hkxq7D6p/z8Ef9Zn/uZ1z onthvoDp+BJOIIa6s68r9rLGNtAQ5/OtxXKpk6Cz5SAUgZIo0p2tNyQ2hFy8ojUZm2hNKVfu 6lN9DcSU0sri8I0S1QIDAQABo4IDhTCCA4EwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6fisKv/TEZ8c96u/L+x4d RtrwdjCBqAYDVR0jBIGgMIGdgBRTcu2SnODaywFcfH6WNU7y1LhRgqGBgaR/MH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eYIBDTAdBgNVHREEFjAUgRJycmVseWVhQHJlZGhhdC5jb20wggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNz bC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRk LjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8E XDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAOBrTD2DJvI0rP6phlUjV0JU6owP2XLQ2fZZ42J LHqfJ+yJWqpprzbHK7c7oJjy/TlNUQzFQZvtQM0WAcopsOzvqeXyB9lt6Zqq1ULMG9s5yMM0 rq/dpYFE2ju9WY8+7962iSkqGmMwrq9ZwO8J37zmMDS3ifw3/n3/Ns1t7MK6tanzkugScuW9 TQr/zQNNanLQmeuvU6Fbru6UFZI6c1qW0G4B1ptfTEQiAQ+E7PdIdjI9SYd24uU6/OdPlGrV tgl0UUnwLuCwA+D84xtc4+TjkLFxuqKCTi0NDONzosPzrNGJ7Kcau5bqV5AUxVz6bUifqQ3a X7xgD7Vq0EGCCK4wggb/MIIF56ADAgECAgMAqykwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0wOTEwMTQwMDAwMDFaFw0xMDEwMTQyMDU0 MjFaMG4xHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVk aGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfXQZsPFfeEcfOIsBOU aYjvrhykuXvdQh5ynybGxDsz8Uux4Is7e/K2rQW4ZLnUO2ySB9aPZ4dEOXPy3TpVlBdSZ/t/ iTRr7Oof75ZnwmBjyk2aVG8D5vEZopPmwzZQDlJA4nmR31IPBznRq6r6daa6qsCzM4KL4uWI hE39vEjvZMTao5GwS1cbAZR654xtXZp/IwGGdVz3LVzBLB1fthCEgzj2FpfwhNo7e5Juh5Ma uw+qf8/BH/WZ/7mdc6J7Yb6A6fgSTiCGurOvK/ayxjbQEOfzrcVyqZOgs+UgFIGSKNKdrTck NoRcvKI1GZtoTSlX7upTfQ3ElNLK4vCNEtUCAwEAAaOCA4UwggOBMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+n4r Cr/0xGfHPervy/seHUba8HYwgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKh gYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQu Y29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQW DVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEt Y3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADga0w9gybyNKz+qYZVI1d CVOqMD9ly0Nn2WeNiSx6nyfsiVqqaa82xyu3O6CY8v05TVEMxUGb7UDNFgHKKbDs76nl8gfZ bemaqtVCzBvbOcjDNK6v3aWBRNo7vVmPPu/etokpKhpjMK6vWcDvCd+85jA0t4n8N/59/zbN bezCurWp85LoEnLlvU0K/80DTWpy0Jnrr1OhW67ulBWSOnNaltBuAdabX0xEIgEPhOz3SHYy PUmHduLlOvznT5Rq1bYJdFFJ8C7gsAPg/OMbXOPk45Cxcbqigk4tDQzjc6LD86zRieynGruW 6leQFMVc+m1In6kN2l+8YA+1atBBggiuMIIH4jCCBcqgAwIBAgIBDTANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGB pH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkw VzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w b2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0 ZXMwDQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP /4H/Bc8FFDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhp cqMr3OyzK3aYGJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyR WTTX6mWSv+TraOwuj3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNh HeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG8 59MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6Gu UcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf 6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIO uAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdC taW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/TyxV/stlehMYID0DCC A8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMAkGBSsO AwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5 MTEwNjIxNDAyMVowIwYJKoZIhvcNAQkEMRYEFHs1Quy2+AX6Emadl187fx9z8+sXMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBAIhtNTQUlyVpsUCPc7o32pzmqRMrQjMRYMctJgBXPdJxQLPBMiyU nbuNy9QsDcWtqpOK1EBFtKPP3yWvI9bTdc6wAHPdy4VrGKWRORfcx4FEmx5UtaOO3tbGLxZM CX2wZ1rQORyFynYifNtQgRWzdW0cK60ncKlfdFAfDkgwMKu+zZdDN0k1ajYxIyhtLXDzC+0w XRqzzKl+SOlqxtQJL6CGqr/teqmzYXCa0a70MNLnvKwr+sQ/w7Ou8Rhxu0Mm1tLxGIVT20OD 5RVQfVtO8806ThzE5jnLbmF0FFcDvb8I7vg45U58rJdoGoPxvwyqFq2A7DYZk6hKNc9QT05z dvoAAAAAAAA= --------------ms020002070805020709060702-- From mike-list@pobox.com Fri Nov 6 14:16:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542483A68E7 for ; Fri, 6 Nov 2009 14:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 83n6IBWXCvei for ; Fri, 6 Nov 2009 14:16:39 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 9BAE93A6823 for ; Fri, 6 Nov 2009 14:16:39 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D8D3A7674C for ; Fri, 6 Nov 2009 17:17:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=LwjREnuTZ+AG +OXt00x9FDLMwgk=; b=MJZQNFYkIxrwLc/V+D7C//5Ma+0Dq2jA1iXp402sh0xR gPchZn7NvyMvqV3cxXNeEDmlRdrxL7TNn5RCyZLDlzzy7KdRuO7VwFikYy6nx8Xp RqqPgiMUi6XY73mtWzYXe12PwHNIgKkSBTcX+EwTGfTQHrMQs8jHKwC0mbah0Ns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=LK9WJt dzSkFGsg8PtVyLut1dkNGgIB8spld3vNUtqAXtj4/+eEwrNoptUyrg4dEUa7BCWA gYjdZp13f5pyHFgNFgwOU7vtpP7e9FfwGmCrTXLOH36UC4DHU/u2OKyRcFj/YWrZ neetqCj0ObD1aF2Xd9tIOJAI4kkP2mCoff2KY= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id CD2FF7674A for ; Fri, 6 Nov 2009 17:17:02 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 800A276748 for ; Fri, 6 Nov 2009 17:17:02 -0500 (EST) Message-ID: <4AF4A091.3070609@pobox.com> Date: Fri, 06 Nov 2009 14:17:53 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> <4AF497C5.5060801@REDHAT.COM> In-Reply-To: <4AF497C5.5060801@REDHAT.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 1C12A5D6-CB22-11DE-A9CB-7C40EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:16:40 -0000 >> Suggestions? >> > For us, this means SSL3 would be dead in the case you require the extension. A server can still negotiate an SSLv3 connection as it does today. It just can't re-negotiate that connection later. This is true for all TLS versions as well; you can still allow unpatched clients to connect, just not renegotiate. The servers impacted by this change are those that require renegotiation to obtain client credentials. Mike From dean@av8.com Fri Nov 6 14:29:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341B43A67FA for ; Fri, 6 Nov 2009 14:29:14 -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 LV6RbX4t5+SV for ; Fri, 6 Nov 2009 14:29:13 -0800 (PST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 1E6AB3A67AD for ; Fri, 6 Nov 2009 14:29:13 -0800 (PST) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id nA6MTNGm006860 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 6 Nov 2009 17:29:24 -0500 Date: Fri, 6 Nov 2009 17:29:23 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Florian Weimer In-Reply-To: <82639ongwg.fsf@mid.bfk.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Eric Rescorla , "tls@ietf.org" Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:29:14 -0000 On Fri, 6 Nov 2009, Florian Weimer wrote: > * Nikos Mavrogiannopoulos: > > > I'll become a bit pedantic and note here that this isn't really a TLS > > issue. Its a TLS issue. However I don't think we should worry too much about https. I've used client certificates on some websites, and let me tell you, its really a non-starter to use renegotation because most webservers have a 250k buffer (On apache this is a compile-time constant) for renegotiation, which isn't big enough to complete a lot of http transactions, anyway. As a result, one usually winds up breaking up websites into two or more sites, with one site completely client certificate controlled so that no renegotation necessary on that site, and the rest of the content is on another site that also needs no renegotiation. > Theoretically, this attack can be detected by the server, Theoretically, I think not. The problem (inherent to every MITM attack) is that there is some plaintext the MITM can change or otherwise use. The solution is the same in every case: Eliminate the plaintext or encrypt it in a (e.g public key) cipher so that the MITM can't alter or read it. That's what should happen here. We should not worry about whether this is hard to program or not. It simply shouldn't be plaintext. I don't think it ought to be too difficult to program, as the client and server have already public exchanged keys that could be used to encrypt the renegotiation. Of course, https is still as screwed as before, but like I said above, it is of no consequence as there are already problems with renegotation that cause renegotiation to be avoided. So we need not worry about https. But renegotiation should be made to work in TLS, as other protocols that rely on TLS don't have the large, essentially unlimited transaction size problems that https has. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494 From ietfdbh@comcast.net Fri Nov 6 14:40:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6484C3A686C for ; Fri, 6 Nov 2009 14:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, SARE_OBFU_ALL=0.751] 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 qEQd+h+hwnZJ for ; Fri, 6 Nov 2009 14:40:16 -0800 (PST) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 603693A682A for ; Fri, 6 Nov 2009 14:40:16 -0800 (PST) Received: from OMTA23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 1xbW1d0011wfjNsAAyghfg; Fri, 06 Nov 2009 22:40:41 +0000 Received: from Harrington73653 ([202.106.79.2]) by OMTA23.emeryville.ca.mail.comcast.net with comcast id 1yoK1d00302zSRE8jyoP2e; Fri, 06 Nov 2009 22:49:09 +0000 From: "David Harrington" To: "'Blumenthal, Uri - 0662 - MITLL'" , "'Nicolas Williams'" , "'Marsh Ray'" References: <20091105223130.GN1105@Sun.COM> Date: Sat, 7 Nov 2009 06:39:48 +0800 Message-ID: <00bb01ca5f32$2a04ed90$1336050a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpeal0YLjVuNje/RNeyNT5lbOFT0AAir4d1AA7cKKA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:40:17 -0000 Hi, I am one of the authors of RFC3411, and lead editor for the ISMS WG as we added support for security protocols at lower layers. I was also involved in the failed EOS WG (Evolution of SNMP) and SMING WG (next generation SMI). I was probably the strongest proponent of using abstract APIs (actually ASIs - abstract service interfaces) to depict data flows between parts of the system. Let me observe that those ASIs have made it almost impossible to update the pieces of SNMPv3, because the ASIs act as design constraints. The strong architectural model made it very difficult to update the SMI without forcing changes to the ASIs. The strong architectural model made it very difficult to update the operations set of the SNMP protocol. Both of these efforts resulted in failed WGs. Adding support for existing SSH security infrastructure took three documents because we had to modify the architecture, including all the affected ASIs. What might have taken months to complete took years - largely because of the use of ASIs in the architecture. Many of the people who worked developed Netconf were involved in the SNMPv3 architecture effort, and subsequent updates. Look at the Netconf architecural model - it uses very simple, very nebulous layering as the borders between portions, not ASIs. This is a dramatically simpler and easier approach to work with. I strongly advise you to be careful what you wish for. > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > Behalf Of Blumenthal, Uri - 0662 - MITLL > Sent: Friday, November 06, 2009 11:24 PM > To: Nicolas Williams; Marsh Ray > Cc: tls@ietf.org > Subject: Re: [TLS] TLS renegotiation issue > > There's an example of using such abstract API in SNMPv3. > Where it was also > debated ("IETF doesn't do API" :-), but the common sense prevailed. > > > On 11/5/09 17:31 , "Nicolas Williams" > wrote: > > > On Thu, Nov 05, 2009 at 04:28:57PM -0600, Marsh Ray wrote: > >> Nicolas Williams wrote: > >>> I don't think it was ever really true that "the IETF > doesn't do APIs". > >> > >> I would add here that if the IETF had compared the way TLS > looks on the > >> wire with how it is presented by SSL APIs in practice, > this defect could > >> not have gone unnoticed. > > > > Indeed. Larry Zhu described to me how the SSPI models TLS > just a few > > days ago. I should have noticed immediately the lack of > binding, but > > because I wasn't also thinking of HTTPS, I didn't. > > > > I'd go far enough to say that we must consider at least > abstract APIs to > > protocols such as TLS. > > > > Nico > > -- > Regards, > Uri uri@ll.mit.edu > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Nicolas.Williams@sun.com Fri Nov 6 15:36:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2399F3A69D0 for ; Fri, 6 Nov 2009 15:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 nMiQ8b6r6wJp for ; Fri, 6 Nov 2009 15:35:59 -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 D168E3A6898 for ; Fri, 6 Nov 2009 15:35:58 -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 nA6NaES4015654 for ; Fri, 6 Nov 2009 23:36:16 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 nA6NaDAc049872 for ; Fri, 6 Nov 2009 16:36:14 -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 nA6N9gdl010471; Fri, 6 Nov 2009 17:09:42 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6N9f9Z010470; Fri, 6 Nov 2009 17:09:41 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Nov 2009 17:09:41 -0600 From: Nicolas Williams To: David Harrington Message-ID: <20091106230941.GK1105@Sun.COM> References: <20091105223130.GN1105@Sun.COM> <00bb01ca5f32$2a04ed90$1336050a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00bb01ca5f32$2a04ed90$1336050a@china.huawei.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: [TLS] To API or not (Re: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 23:36:00 -0000 On Sat, Nov 07, 2009 at 06:39:48AM +0800, David Harrington wrote: Of course, the issue here is not "must the IETF provide APIs?" but "can the IETF provide APIs?". The answer to that is a resounding "yes". > I was probably the strongest proponent of using abstract APIs > (actually ASIs - abstract service interfaces) to depict data flows > between parts of the system. > > Let me observe that those ASIs have made it almost impossible to > update the pieces of SNMPv3, because the ASIs act as design > constraints. The strong architectural model made it very difficult to > update the SMI without forcing changes to the ASIs. The strong > architectural model made it very difficult to update the operations I consider this a feature. Not that I want to slow down development, mind you. Nor that I want to stay wedded to an ASI architecture that turns out to be resistant to usefule changes. Rather, changes to the protocol should either be mindful of the abstract interfaces that have been specified (i.e., the existing interfaces, possibly with extensions, should continue to work), or they should introduce a replacement set of interfaces. > set of the SNMP protocol. Both of these efforts resulted in failed > WGs. Adding support for existing SSH security infrastructure took > three documents because we had to modify the architecture, including > all the affected ASIs. What might have taken months to complete took > years - largely because of the use of ASIs in the architecture. If the ASIs made it too hard to change the protocol in useful ways, then the ASIs should be replaced. > Many of the people who worked developed Netconf were involved in the > SNMPv3 architecture effort, and subsequent updates. Look at the > Netconf architecural model - it uses very simple, very nebulous > layering as the borders between portions, not ASIs. This is a > dramatically simpler and easier approach to work with. I agree that it is dramatically simpler to write such documents. I don't agree that the result is necessarily better. There's a whole continuum of degree of formalism that we can use in our documents. What degree of formalism is best will depend on context (including who the document authors and implementors are). There will be contexts where using XML schemas is useful, and ones where that would be overkill, for example; replace XML with ASN.1/SDL/whatever. There are contexts where you want to use pseudo-code, or even actual source code to describe as formally as possible, what must be done, while in other contexts "test vectors", or just plain English language prose will do. I think that abstract interfaces would be useful for TLS. Most would probably disagree. If someday I get to be a TLS implementor, I may well submit an individual submission I-D describing an abstract TLS API, and maybe then I can convince the rest. Until then I'm happy to be in the minority, with some minor exceptions: I think it's important forthe base TLS spec to speak of TLS connections, channel bindings for TLS connections, and channel binding to TLS connections. > I strongly advise you to be careful what you wish for. Thanks. Nico -- From marsh@extendedsubset.com Fri Nov 6 15:41:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2933A6921 for ; Fri, 6 Nov 2009 15:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 d080uskkZMXg for ; Fri, 6 Nov 2009 15:41:02 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 38F5E3A68F9 for ; Fri, 6 Nov 2009 15:41:02 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6YQn-000DZj-EE for tls@ietf.org; Fri, 06 Nov 2009 23:41:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 91150667B for ; Fri, 6 Nov 2009 23:41:23 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/LcBh9/i5UdFRMerVDnNsVLAxrSEGYc9k= Message-ID: <4AF4B423.2000309@extendedsubset.com> Date: Fri, 06 Nov 2009 17:41:23 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> <4AF497C5.5060801@REDHAT.COM> <4AF4A091.3070609@pobox.com> In-Reply-To: <4AF4A091.3070609@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 23:41:03 -0000 Michael D'Errico wrote: > > A server can still negotiate an SSLv3 connection as it does today. > It just can't re-negotiate that connection later. But on the server question: There is a large, but unknown, group of sites that really depend on being able to serve different requirements for client certs from the same IP. For example, one development tool widely used in the industry is MS Visual Studio 2005. It provides a nice IDE for developing web apps (among other things). It has wizards all over the place. One will generate a "web service" project, another will make an installer for it. This WS architecture frequently uses client cert authentication and IIS provides features to map client certs to OS user accounts. There are other client auth schemes in use, too, pretty much anything supported by HTTP. Server certs are expensive (or require approval to obtain) so I suspect it's very common to serve web service projects requiring client cert auth from the same hostname and IP as a web site that does not. Just making an argument for how important per-request renegotiation is in some deployments. My guess is that any patch introducing an (SSLv3 xor renegotiation) requirement is likely to cause a bit of headache. Consider the possibility that a developer has an app that he tests and works fine on his machine. But once he installs his app on the production server, all the sudden some mysterious subset of clients (those using SSLv3) will stop being able to connect to some different service which shares the same IP address. Trial-and-error troubleshooting causes puts the blame on the developer. We should consider the possibility that it could introduce more (and more confusing) incompatibilities than just deprecating SSLv3 outright. > This is true for > all TLS versions as well; you can still allow unpatched clients to > connect, just not renegotiate. I strongly suspect it also applies to many SSLv3 clients. - Marsh From mrex@sap.com Fri Nov 6 15:53:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A698D3A690F for ; Fri, 6 Nov 2009 15:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=0.144, 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 AKY32Lc9A9WZ for ; Fri, 6 Nov 2009 15:53:25 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 79ADB3A6898 for ; Fri, 6 Nov 2009 15:53:25 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA6Nrlr7019081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 00:53:47 +0100 (MET) From: Martin Rex Message-Id: <200911062353.nA6NrkWu014870@fs4113.wdf.sap.corp> To: noskov@microsoft.com (Nasko Oskov) Date: Sat, 7 Nov 2009 00:53:46 +0100 (MET) In-Reply-To: from "Nasko Oskov" at Nov 6, 9 08:38:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 23:53:26 -0000 Nicolas Williams wrote: > > Stop using SSLv3. Its end has arrived. I was actually looking for an answer from engineering, not for one from sales. :-| We might need to ask a few hundred million users to enable TLS 1.0 on their MSIE browsers running on Windows XP. And you really should not underestimate the amount of software where it needs much more that a registry key to obtain TLS support. The answer might not be as simple as saying "drop SSLv3 support". Nasko Oskov wrote: > > Dare I say block renegotiations in SSLv3? Most implementations > have had TLS1.0 support for a long time, so compatibility > impact should be fairly low. That misses the point somewhat. There are several aspects that need to be addressed. *I* do not have a problem with requiring servers that want to continue using renegotiation to upgrade to at least TLSv1.0. I think that is doable. But what are we going to require from Servers that use the delayed authentication through renegotiation, and want to continue using it when SSLv3 clients connect (either stuck at or configured for SSLv3 only)? I think we ought to require them to refuse traditional renegotiation in the future (what should they send back to v3.0 clients trying)? They could send a CertificateRequest to v3 clients in the initial full handshake instead (causing a slightly different "user experience" to TLSv1.x clients with delayed authentication). I would like to require them to do that (if they support client-cert authentication) but I do not think we can do that, and I have no idea how difficult that would be for the various servers to implement. But all that doesn't give the clients the possibility to protect themselves from the MITM attack (that what is described in the client considerations of Eric's proposal). It leaves an extremely bad taste if we push people with software that is not vulnerable in order to protect against a vulerability of a number of broken servers with whom they're not affiliated. What would you think if suddenly someone in your street would get himself a very dangerous, huge and badly tempered dog and he would let him outside regularly -- with no fence and no leash and the other 12 neighbours in the street would have to put up fences around their property to protect from that dog. IMHO, the guy with the dog should be required to either build a fence around his property, put the dog on a leash or chain or get rid of it. If we agree on a fix to this problem in TLS, and the deployment results in interoperability problems that can _not_ be easily fixed (and it is naive to assume there will not be any, the installed base is so awfully large), then the wording of our specification and requirements may make a difference on who will have to change what based on contractual obligations. (IANAL though) And personally, I think that neither "Your SSLv3 client is to old" nor "get the update for your TLSv1.0 client" is a justified position, because in most cases it is purely a problem of the server. There also is a much higher likelyhood of servers being under maintenance (support contract), than clients. -Martin From Nicolas.Williams@sun.com Fri Nov 6 16:06:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7263A6898 for ; Fri, 6 Nov 2009 16:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 GFjsIH5c+lNd for ; Fri, 6 Nov 2009 16:06:36 -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 E27713A67A2 for ; Fri, 6 Nov 2009 16:06:35 -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 nA706xg6015305 for ; Sat, 7 Nov 2009 00:06:59 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 nA706xF5063988 for ; Fri, 6 Nov 2009 17:06:59 -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 nA6Nlwoc010497; Fri, 6 Nov 2009 17:47:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6NlwJb010496; Fri, 6 Nov 2009 17:47:58 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Nov 2009 17:47:58 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091106234757.GN1105@Sun.COM> References: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> <4AF497C5.5060801@REDHAT.COM> <4AF4A091.3070609@pobox.com> <4AF4B423.2000309@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF4B423.2000309@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: [TLS] Simple way to drop re-negotiation in HTTP (Re: draft-rescorla-tls-renegotiate.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 00:06:36 -0000 On Fri, Nov 06, 2009 at 05:41:23PM -0600, Marsh Ray wrote: > Michael D'Errico wrote: > > > > A server can still negotiate an SSLv3 connection as it does today. > > It just can't re-negotiate that connection later. > > But on the server question: > > There is a large, but unknown, group of sites that really depend on > being able to serve different requirements for client certs from the > same IP. The simplest way to drop re-negotiation in web servers is this (based on an idea by Nelson Bolyard): - start two instances of the web server, one on an alternate port number, with the same contents - the primary instance will accept TLS user authentication, but will not require it - the instance on the alternate port will always require TLS user authentication - neither instance accepts TLS re-negotiations - whenever the primary instance of the web server would request user authentication via TLS do this instead: re-direct to client to the same resource on the alternate port. That's almost entirely automatic. The only thing a webmaster must do is pick a suitable port number for the instance that requires user authentication. The redirects will add some round-tripage. They can be avoided somewhat by re-writing URLs in contents served to point to the right server instance. Ugly, yes, but automatable. Nico -- From Nicolas.Williams@sun.com Fri Nov 6 16:10:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7800B28C0D6 for ; Fri, 6 Nov 2009 16:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 ub2z5Dr0vsnj for ; Fri, 6 Nov 2009 16:10:48 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 21C5628B797 for ; Fri, 6 Nov 2009 16:10:48 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA70BAv3028047 for ; Sat, 7 Nov 2009 00:11:11 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 nA70BA9j000246 for ; Fri, 6 Nov 2009 17:11:10 -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 nA6NxdsC010506; Fri, 6 Nov 2009 17:59:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6Nxcia010505; Fri, 6 Nov 2009 17:59:38 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 6 Nov 2009 17:59:38 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091106235938.GO1105@Sun.COM> References: <200911062353.nA6NrkWu014870@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911062353.nA6NrkWu014870@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: Nasko Oskov , tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 00:10:49 -0000 On Sat, Nov 07, 2009 at 12:53:46AM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > Stop using SSLv3. Its end has arrived. > > I was actually looking for an answer from engineering, > not for one from sales. :-| :/ Right, the real choice is: stop using re-negotiation without the fix and/or stop using TLS without the fix (which means stop using SSLv3). The first choice leaves clients without the fix vulnerable when they talk to servers that don't have the fix and do accept re-negotiation. That's pretty bad (surely many servers won't get the short-term fix). The second choice renders a large portion of the installed base non-interoperable. That's... much worse. I don't know how addicted we are to re-negotiation and SSLv3, so I can't tell you which choice should win in the short-term, but then, I think turning off re-negotiation may well prove easier than we may have thought (see my reply to Marsh just now). In the longer term though, we should deploy the fix and SSLv3 clients should go away. Nico -- From nelson@bolyard.me Fri Nov 6 16:15:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5532A28C0F2 for ; Fri, 6 Nov 2009 16:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.203, 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 PdBlfc7FWyhb for ; Fri, 6 Nov 2009 16:15:57 -0800 (PST) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 846DA28C0EE for ; Fri, 6 Nov 2009 16:15:57 -0800 (PST) Received: (qmail 28461 invoked from network); 7 Nov 2009 00:16:20 -0000 Received: from unknown (67.188.69.99) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 07 Nov 2009 00:16:19 -0000 Message-ID: <4AF4BC4E.9080900@bolyard.me> Date: Fri, 06 Nov 2009 16:16:14 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: IETF TLS Working Group References: <200911062353.nA6NrkWu014870@fs4113.wdf.sap.corp> In-Reply-To: <200911062353.nA6NrkWu014870@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 00:15:58 -0000 On 2009-11-06 15:53 PDT, Martin Rex wrote: > But what are we going to require from Servers that use the delayed > authentication through renegotiation, and want to continue using it > when SSLv3 clients connect (either stuck at or configured for SSLv3 only)? > > I think we ought to require them to refuse traditional renegotiation > in the future (what should they send back to v3.0 clients trying)? Here is an alternative that should have the same user experience and not be MITM vulnerable, not even with SSL 3.0 clients: Replace renegotiation with redirection. Set up a second https server (process) on the same physical server, e.g a different port on the same IP address. The new server always requests client authentication on the initial handshake, not in a renegotiation. All the assets that formerly lived in the original server and formerly required renegotiation for client authentication are moved to the second server on the new port. In their place on the original server in placed something that redirects the user to the asset's new location on the new server. The user visits the first server, and is redirected to the second server, whereupon he is asked for his client certificate. This all seems to him the same as before, but no renegotiation has occurred. Since the two servers reside on the same IP address and same box, they can share the same certificate and private key, so there is no additional cost for additional certificates (sorry, CAs). The only area where this MAY not work that occurs to me is POST. I seem to recall that some (most? all?) browsers will not re-POST data if they get a redirect after doing the initial POST. So, the two servers might have to collude (:-), with the first server saving the POST data, and setting a cookie, or putting a unique string into the redirected URL that the second server could use to find the data saved by the first server, after the user authenticates to it. (Maybe somebody come up with a better alternative to that.) From mike-list@pobox.com Fri Nov 6 16:18:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23FE28C0FF for ; Fri, 6 Nov 2009 16:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 051oDvlcgkl8 for ; Fri, 6 Nov 2009 16:18:56 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id DFB7E28C0F8 for ; Fri, 6 Nov 2009 16:18:55 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id F0EC576192 for ; Fri, 6 Nov 2009 19:19:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=+/fAMyYuH7VX jGVre1vi8+YScek=; b=Nr51SDmsFokGfFWtQ7XuR2p4G2UGB1OF9Qw6D7DbBVKd WU20JKmvbbQMWhRcPXrlTl/GXVscwtHoN6H3FN90naZI8ajDHm6KLEtZWOYvGIP1 h8MG7eS037NiRbaK4odsuawbZz9e5dJ59qsw5eiISuO3sfaYg2oUBUWG2acKD1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=fKEueZ gY2fEJKUmV7BMPCswoiabwwKZScqvghwDtCxKIMKd8Quy235A16xv5WGISP6jxJt SyvId8N2ndvotKzpKHkG3jnqXWsExcJKc8+z3kA9LI16Aj+PeP1+uE1JbGg2hGnW YTYW6rewQSN4ishHz6op8kdaBskjTDrhIbKcA= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EEEC676191 for ; Fri, 6 Nov 2009 19:19:18 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9FF3F76190 for ; Fri, 6 Nov 2009 19:19:18 -0500 (EST) Message-ID: <4AF4BD3A.6030507@pobox.com> Date: Fri, 06 Nov 2009 16:20:10 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911052021.nA5KLiAu010298@fs4113.wdf.sap.corp> In-Reply-To: <200911052021.nA5KLiAu010298@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 30C2551A-CB33-11DE-B680-7C40EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 00:18:56 -0000 Martin Rex wrote: > > Eric's proposal to make renegotiation secure does not need any > API-level changes, everything is completely internal to the > TLS protocol engine. Having finished implementing the proposal, I can say that this is a true statement. No API changes were required. Mike From mrex@sap.com Fri Nov 6 16:27:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554E328C0F9 for ; Fri, 6 Nov 2009 16:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.114 X-Spam-Level: X-Spam-Status: No, score=-6.114 tagged_above=-999 required=5 tests=[AWL=0.135, 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 BnuuX4f61G1r for ; Fri, 6 Nov 2009 16:27:38 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5B5E93A6905 for ; Fri, 6 Nov 2009 16:27:38 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA70S0jC008676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 01:28:00 +0100 (MET) From: Martin Rex Message-Id: <200911070028.nA70S0Ef016701@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Sat, 7 Nov 2009 01:28:00 +0100 (MET) In-Reply-To: <4AF4BD3A.6030507@pobox.com> from "Michael D'Errico" at Nov 6, 9 04:20:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 00:27:39 -0000 Michael D'Errico wrote: > > Martin Rex wrote: > > > > Eric's proposal to make renegotiation secure does not need any > > API-level changes, everything is completely internal to the > > TLS protocol engine. > > Having finished implementing the proposal, I can say that this is > a true statement. No API changes were required. Nico has drawn a raw sketch about SSPI (Microsoft schannel), and that API will probably require a minor change. I have not personal experiences with schannel, but from what Nico described, I think a single new API function and slight modification of the context iteration functions might be sufficient (as discussed earlier postings). CreateRenegoSecurityContext(prev_context, options, &new_context); -Martin From mrex@sap.com Fri Nov 6 16:39:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB173A6A83 for ; Fri, 6 Nov 2009 16:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, 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 Y69D-GUkhEq2 for ; Fri, 6 Nov 2009 16:39:43 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3D0F03A6824 for ; Fri, 6 Nov 2009 16:39:43 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA70e5aI016543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 01:40:05 +0100 (MET) From: Martin Rex Message-Id: <200911070040.nA70e4oH017413@fs4113.wdf.sap.corp> To: rrelyea@redhat.com (Robert Relyea) Date: Sat, 7 Nov 2009 01:40:04 +0100 (MET) In-Reply-To: <4AF497C5.5060801@REDHAT.COM> from "Robert Relyea" at Nov 6, 9 01:40:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 00:39:44 -0000 Robert Relyea wrote: > > >> Even more importantly, SSLv3 does not support extensions. > >> > > You're correct. SSLv3 allows extensions in the ClientHello that > > are to be ignored, but it does not support them in ServerHello. > > In practice, there are too many servers that blow up even on extensions > in clientHellos. So many that NSS only uses extensions in TLS, not in SSL3. I have no data and no experiences about interop issues with >SSLv3. Networking or multimedia appliances might be the hardest to get upgraded, although they're quite unlikely themselves to use client-cert authentication, much less through renegotiation. We shouldn't unnecessarily create interop-problems with them (or force them to drop to plain http). What exactly do you mean by "only uses extensions in TLS"? TLS extensions must be asserted in the ClientHello, and a SSLv3 server is expected to ignore them. Are you rather referring to fallback/reconnect-heuristics in Browsers that will automatically re-try a failed TLS-handshake with TLS extensions by a SSLv3 handshake without TLS extensions. Which Browsers&Versions do that, actually (I simply don't know)? Such a fallback would certainly help, but is entirely an apps issue. It is much less likely to be present in programmatic clients, I assume. -Martin From mrex@sap.com Fri Nov 6 17:00:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90ECD3A67F3 for ; Fri, 6 Nov 2009 17:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, 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 rjyGSBOymdss for ; Fri, 6 Nov 2009 17:00:26 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 96AA93A67A8 for ; Fri, 6 Nov 2009 17:00:26 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA710kHA001934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 02:00:46 +0100 (MET) From: Martin Rex Message-Id: <200911070100.nA710jJO018486@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Sat, 7 Nov 2009 02:00:45 +0100 (MET) In-Reply-To: <4AF4BC4E.9080900@bolyard.me> from "Nelson B Bolyard" at Nov 6, 9 04:16:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 01:00:27 -0000 Nelson B Bolyard wrote: > > Here is an alternative that should have the same user experience and not > be MITM vulnerable, not even with SSL 3.0 clients: > > Replace renegotiation with redirection. > > Set up a second https server (process) on the same physical server, e.g > a different port on the same IP address. The new server always requests > client authentication on the initial handshake, not in a renegotiation. That is actually what our clients usually have to do since the OEM SSL/TLS library we provide does not support renegotiation on the server side (its also not in our apps software layers). There is one itch I have with this: A number of Web Proxies (like the one of our company) does not permit HTTP CONNECT to ports other than 443. Should we ask for an additional port to be officially allocated to http-over-ssl-with-client-cert so that we can get this past our security policy (not joking)? -Martin From marsh@extendedsubset.com Fri Nov 6 22:00:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAFB93A6881 for ; Fri, 6 Nov 2009 22:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 DGnNDnOEKPnG for ; Fri, 6 Nov 2009 22:00:08 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id D0C783A6939 for ; Fri, 6 Nov 2009 22:00:07 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6eLf-000Cjr-1f for tls@ietf.org; Sat, 07 Nov 2009 06:00:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 011EC667B for ; Sat, 7 Nov 2009 06:00:29 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18j0AJ/uNzR8KVFXTQLDqpS8pWq4B0r7dA= Message-ID: <4AF50CFD.7070705@extendedsubset.com> Date: Sat, 07 Nov 2009 00:00:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> <4AF497C5.5060801@REDHAT.COM> <4AF4A091.3070609@pobox.com> <4AF4B423.2000309@extendedsubset.com> <20091106234757.GN1105@Sun.COM> In-Reply-To: <20091106234757.GN1105@Sun.COM> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Simple way to drop re-negotiation in HTTP (Re: draft-rescorla-tls-renegotiate.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 06:00:09 -0000 Nicolas Williams wrote: > The simplest way to drop re-negotiation in web servers is this (based on > an idea by Nelson Bolyard): > > - start two instances of the web server, one on an alternate port > number, with the same contents > > - the primary instance will accept TLS user authentication, but will > not require it > > - the instance on the alternate port will always require TLS user > authentication > > - neither instance accepts TLS re-negotiations > > - whenever the primary instance of the web server would request user > authentication via TLS do this instead: re-direct to client to the > same resource on the alternate port. > > That's almost entirely automatic. > The only thing a webmaster must do is > pick a suitable port number for the instance that requires user > authentication. Wow that does make it sound easy. All we need to do for HTTPS is get a new port number assigned and the entire burden of the solution passes from the TLS specs to server implementors and site admins? Think of what this is proposing: all sites that currently depend on renegotiation have to adjust their configuration. They have to reconfigure their server's internal filters to allow the port. They have to reconfigure their border firewalls to allow the new port. Every web proxy device has to be reconfigured to support the new port. Web applications that check for that magic number 443 will need to be updated. We'll ignore reverse proxies and SSL offload for now. Say only 5% of sites depend on renegotiation. OK, only 5% admins need to reconfigure. Well, how well-tested is everything outside of those admins' networks going to be? How well does the 5% case tend to work end-to-end? Every client-side filter that watches outbound connections has to know what that new port is being used for. Non-browser client code has to be reviewed and possibly rewritten because it doesn't necessarily follow HTTP redirects. Same-origin policies for cookies have to be checked for how they handle the redirect to the new port. Suppose that some ecommerce retailer is sending free smart-cards and usb readers to 500K of their best customers this year (I got one in the mail a few years ago). These cards web-enabled! (I.e. they present client certs under the hood.) Armies of young, energetic support people will spend the best years of their careers explaining to end users how to reconfigure their ZoneAlarm. > - neither instance accepts TLS re-negotiations Oh yes, even with all that...you still need to update every web server and client and TLS stack in the world! > The redirects [] can be avoided somewhat > by re-writing URLs in contents served to point to the right server > instance. Oh my. - Marsh From djhopwood@googlemail.com Fri Nov 6 22:18:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5543A6A18 for ; Fri, 6 Nov 2009 22:18:14 -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 9kvCvO9+2sD6 for ; Fri, 6 Nov 2009 22:18:13 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 443A23A6A26 for ; Fri, 6 Nov 2009 22:18:13 -0800 (PST) Received: by ewy3 with SMTP id 3so1710950ewy.37 for ; Fri, 06 Nov 2009 22:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type; bh=CLhTl8dAfaGGElb8iamHI/Xz125EcCE/6GApBtXlSp8=; b=SzvXt6cbWb10E+AX7DlN6Z9JJdxCOX+SFJEiA2EnSmdQoE1klqeJ3lxwO2f8n3KaON fsdzdas4k/haVAvFDP/M/3ws/InnQR/jJP/ND2EcJwDwjHRgzQuBRTO43/utgMSmas/k PD2D8ZQ0tU3SVTsiG0ARHANMCcvZu8Ks5J/1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; b=JsJuuGP5ygZCRaUceZfrwsBil1+Gm/ouECNRt6PxuB4f9Nh2n/uohhmC7HkoC4otJi cns11qikBppK7hIevNGmBSeDNaKDAs6lIvhymkJJtw7QRdaHo30NcYl7BFc/FqGJl2wa 0Hq4f+pD/gb0xjxvSVQPRikmtgcotTGSI+YJ4= Received: by 10.213.68.143 with SMTP id v15mr346043ebi.45.1257574713585; Fri, 06 Nov 2009 22:18:33 -0800 (PST) Received: from ?192.168.0.2? (5e025226.bb.sky.com [94.2.82.38]) by mx.google.com with ESMTPS id 7sm457243eyb.16.2009.11.06.22.18.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Nov 2009 22:18:33 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF5112E.2070809@jacaranda.org> Date: Sat, 07 Nov 2009 06:18:22 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig12E331B6CDC592B8905C717A" Subject: [TLS] Comments on draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 06:24:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig12E331B6CDC592B8905C717A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Comments on https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renego= tiate.txt Overall I think this draft is a good solution to the identified security problem. The draft defines an extension that affects renegotiation, which might be perceived to conflict with RFC 3546 section 2.3: Finally note that all the extensions defined in this document are relevant only when a session is initiated. However, a client that requests resumption of a session does not in general know whether the server will accept this request, and therefore it SHOULD send an extended client hello if it would normally do so for a new session. If the resumption request is denied, then a new set of extensions will be negotiated as normal. If, on the other hand, the older session is resumed, then the server MUST ignore extensions appearing in the client hello, and send a server hello containing no extensions; in this case the extension functionality negotiated during the original session initiation is applied to the resumed session. The intent of this restriction (that "the server MUST ignore extensions appearing in the client hello, and send a server hello containing no extensions" when a session is resumed) was that it would potentially simplify security analysis of TLS, by justifying an assumption that the extension-based options used in a session stay the same across resumption= s (see ). It wasn't intended (at least not by me, as one of the authors of RFC 3546= ) to preclude the definition of extensions that are specifically designed to affect renegotiation. But since it could be interpreted that way, I think that the draft should explicitly clarify this point. Another issue is that a server that supports the extension can refuse the renegotiation. The current draft is not clear about what the client and server behaviour should be in that case. Suggestion: If a ClientHello that is requesting to resume a previous session contains a Renegotiation_Info extension, and the server supports the extension but wishes to refuse the renegotiation, it SHOULD reply with a zero-length Renegotiation_Info. If a client that is requesting to resume a session receives a zero-length Renegotiation_Info without a no_renegotiation alert, it MUST abort the handshake. If it receives both a zero-length Renegotiation_Info and a no_renegotiation alert, then the fact that the Renegotiation_Info contents do not match the previous session's verify_data values should not be considered a reason for the client to abort. Note that one legitimate reason for refusing a renegotiation is that the old session has expired, in which case the server is likely to have forgotten the client and server verify_data values for that session. Nevertheless it SHOULD reply with a Renegotiation_Info to indicate that it supports the extension. For the same reason, when the server refuses a renegotiation it may not have the ability to check that the contents of the client's Renegotiation_Info were correct. Therefore, there should be no requirement for the server to check the contents in that case. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig12E331B6CDC592B8905C717A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr1ETYACgkQWUc8YzyzqAdIYQD/Q0bWKl3RdEJDKefi+Y2slRUv H+I5DBW9liV9XayOh6AA/i7nPIU+dhSJSRciQRh9+h/GofSSq/1brsuHR/WKIMlf =jql/ -----END PGP SIGNATURE----- --------------enig12E331B6CDC592B8905C717A-- From djhopwood@googlemail.com Fri Nov 6 22:35:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523283A690B for ; Fri, 6 Nov 2009 22:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.631, 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 QxwEs8QErlSd for ; Fri, 6 Nov 2009 22:35:09 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 4EF273A67A3 for ; Fri, 6 Nov 2009 22:35:09 -0800 (PST) Received: by ewy3 with SMTP id 3so1715067ewy.37 for ; Fri, 06 Nov 2009 22:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=gCM5pqLkxihTFHBoriQp6p8Clr4xYXyMPdAyy4u+YJQ=; b=MEnzSh1BkNlmxebRp8N3MBbzNpaZvJtlXgiRa+UFIL/b+Ly15LhlHTuZ4Q6hkpX7R8 gqwo8bOwh3VBEacB4xmRi+HEF5v1+1pJweLm4QQP5JV8RZgJ7i4XwANL07E41dxM05gr PrSvDHuY222CtByNb/Tr1Zvx1VRh6mmfwNnL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=RmeXesryy+a2OhX0PY2PxgIodKBAzFkguqKPgmNen1Mb2sgmPhnj5m4lKOqlZiaoO9 P86NXMdOZIjxm2zqOhLxjfof9DGkDPkwPy5d8FElkSLmuwlhAg9PuAoCt1Yw4mGY/PW3 S5XspdjyB+OubJ7fNHvhS8mt7uGP+EARCkRn4= Received: by 10.213.104.75 with SMTP id n11mr4353433ebo.70.1257575732698; Fri, 06 Nov 2009 22:35:32 -0800 (PST) Received: from ?192.168.0.2? (5e025226.bb.sky.com [94.2.82.38]) by mx.google.com with ESMTPS id 7sm485491eyb.8.2009.11.06.22.35.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Nov 2009 22:35:32 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF51527.5060404@jacaranda.org> Date: Sat, 07 Nov 2009 06:35:19 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AF5112E.2070809@jacaranda.org> In-Reply-To: <4AF5112E.2070809@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig78606FA1DFD4566081965DA6" Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 06:35:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig78606FA1DFD4566081965DA6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Comments on > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-rene= gotiate.txt >=20 > Overall I think this draft is a good solution to the identified securit= y > problem. >=20 > The draft defines an extension that affects renegotiation, which might > be perceived to conflict with RFC 3546 section 2.3: Ah, I should have been referencing RFC 4366 section 3 -- but the wording is almost the same: Note also that all the extensions defined in this section are relevant only when a session is initiated. When a client includes one or more of the defined extension types in an extended client hello while requesting session resumption: - If the resumption request is denied, the use of the extensions is negotiated as normal. - If, on the other hand, the older session is resumed, then the server MUST ignore the extensions and send a server hello containing none of the extension types. In this case, the functionality of these extensions negotiated during the original session initiation is applied to the resumed session. and the same comments apply. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig78606FA1DFD4566081965DA6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr1FTAACgkQWUc8YzyzqAeXzQD/cAwn2+qxFM7S/DwRcg+bFLf0 5tm2hOBIsJwrCA233twBAIBGJi0NscO0nM5PZK+Pobm+oFnotOOkxRSx+4syl0v/ =IaTm -----END PGP SIGNATURE----- --------------enig78606FA1DFD4566081965DA6-- From n.mavrogiannopoulos@gmail.com Sat Nov 7 00:01:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10343A693D for ; Sat, 7 Nov 2009 00:01:25 -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 Y6HdPrggS4Xl for ; Sat, 7 Nov 2009 00:01:24 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 8D83D3A687E for ; Sat, 7 Nov 2009 00:01:24 -0800 (PST) Received: by bwz23 with SMTP id 23so1910738bwz.29 for ; Sat, 07 Nov 2009 00:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Tjw696Ln5KSI8yPJiYOeerx2xiObMVaPUxhZqinTs7Q=; b=CERzDLqPt3R4pFVMHid1TkVuDxUIEAyS1pit1mCbKKSoNyZIV+7tV1xjU+wTzUIfLx HpuOakk4rJmK9OY+1GnxzWG4L9aY5ZsY4Yi7SuOmOguLsbKw7WrlZK3sYvIScipP8Xu6 q0x+/WYfGB6hVm71ktfPVhlEw3XG/S37LU3ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=oJj/zwmw0LS3VKtnnaqwPcxhP8I1ngkfz4JM3BXmjypL7AualESQ2vbEgM5U+rudOM t2/aY/7h0Mg098RjFAiU2Unr5fg6Wy3ICtUWqBzKECvC7t5oAYebBHBSCY0nqm+4mrR2 mu33mOhRdlHgihpSVHrMHvfmbLW8ryljH9JZ4= Received: by 10.204.156.203 with SMTP id y11mr5338535bkw.200.1257580905240; Sat, 07 Nov 2009 00:01:45 -0800 (PST) Received: from ?10.100.1.196? (adsl27-67.ath.forthnet.gr [77.49.218.67]) by mx.google.com with ESMTPS id d13sm1516994fka.22.2009.11.07.00.01.43 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Nov 2009 00:01:44 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4AF52966.3070400@gnutls.org> Date: Sat, 07 Nov 2009 10:01:42 +0200 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: mrex@sap.com References: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp> In-Reply-To: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 08:01:25 -0000 Martin Rex wrote: > For re-negotiations, the following requirement from > rfc5246 6.2.1. Fragmentation (last paragraph): > > Note: Data of different TLS record layer content types MAY be > interleaved. Application data is generally of lower precedence for > transmission than other content types. However, records MUST be > delivered to the network in the same order as they are protected by > the record layer. Recipients MUST receive and process interleaved > application layer traffic during handshakes subsequent to the first > one on a connection. > > Provides and interesting additional challenge, and documents that > at least some of the original protocol designers didn't sufficiently > reflect on the implications. > > Similarly rfc-5246, 7.4.1.1. Hello Request > > Since handshake messages are intended to have transmission > precedence over application data, it is expected that the > negotiation will begin before no more than a few records are > received from the client. If the server sends a HelloRequest but > does not receive a ClientHello in response, it may close the > connection with a fatal alert. > > I think it is underspecified what "interleaved application data > and handshake messages" and "handshake message have transmission > precedence over application data" is supposed to mean, and > what kind of signalling would be necessary between the > TLS protocol stack and the application caller in order > to convey the underspecified semantics unambiguously. Actually as far as I remember this was the most tricky part of TLS (any version) to implement in a sensible transparent way. Moreover the way I have implemented it, although not so transparent, the application layer cannot distinguish between the two sessions (one before renegotiation, one after). The problem was for me that you could receive any amount of application data even after a rehandshake was requested, thus I had to cache them and present to the application after rehandshake was finished. [...] > From the original design, and in the two quoted paragraphs above, > it appears that SSL and its successor TLS was intended to be > _very_ transparent, and the spec contains guidance for > security-relevant signaling to the application only for > the initial TLS handshake on a connection (full initial handshake, > and session resume), but _NOT_ for the session renegotiation. > > Therefore, I think, we do have a real shortcoming of the > SSL/TLS protocol, and we really should scramble to fix it. > > That includes improving on the guidance for the signaling > and semantics of a TLS session renegotiate of the TLS > protocol stack to the application -- in a fashion so that > it can be folded back into rfc5246bis. I agree this part of TLS needs to become more clear in semantics and more strict in specification. For example what has to be done by a client if a handshake request was received. Currently some client may ignore it. How long is the server going to wait to understand that it was ignored and no reply is expected? regards, Nikos From marsh@extendedsubset.com Sat Nov 7 00:30:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931863A680D for ; Sat, 7 Nov 2009 00:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.267, 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 pnSxeU8ttsf1 for ; Sat, 7 Nov 2009 00:30:10 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id D15CA3A63EC for ; Sat, 7 Nov 2009 00:30:10 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6ggs-000Bnj-2d for tls@ietf.org; Sat, 07 Nov 2009 08:30:34 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0D329667B for ; Sat, 7 Nov 2009 08:30:33 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/uHFtQaNt9rkmYoih9gtlQrLNBKz1Ata8= Message-ID: <4AF53027.6030701@extendedsubset.com> Date: Sat, 07 Nov 2009 02:30:31 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp> <4AF52966.3070400@gnutls.org> In-Reply-To: <4AF52966.3070400@gnutls.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 08:30:11 -0000 Nikos Mavrogiannopoulos wrote: > > the application layer > cannot distinguish between the two sessions (one before renegotiation, > one after). The problem was for me that you could receive any amount of > application data even after a rehandshake was requested, thus I had to > cache them and present to the application after rehandshake was finished. Yes, yes! The buffered stream IO model we all take for granted is insufficient to represent the semantics of a TLS connection in the presence of renegotiation! Even with an added callback for cert validation, ambiguities linger! I think it highly probable that real vulnerabilities exist in applications due to this mismatch. The draft-rescorla-tls-renegotiate extension should help quite a bit though. - Marsh From rea-sec@codelabs.ru Fri Nov 6 12:05:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B84B3A67B6 for ; Fri, 6 Nov 2009 12:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.804 X-Spam-Level: ** X-Spam-Status: No, score=2.804 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DATE_IN_FUTURE_03_06=0.274, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, J_CHICKENPOX_23=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYRo34pcF5fD for ; Fri, 6 Nov 2009 12:05:11 -0800 (PST) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by core3.amsl.com (Postfix) with ESMTP id C023D3A6809 for ; Fri, 6 Nov 2009 12:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Date:From:To:Cc:Subject:Message-ID: Reply-To:References:MIME-Version:Content-Type:In-Reply-To: Sender; bh=hrmFHl2P0u6L/pQ8PoRaDy+2i4BcAzVqt/08vKsgi2U=; b=aFu6p iZniN467lFjWg2on6RutbGTg3hTJpoecAyyy4vgGkOUq6yXS3xt5ExcZyb3PhSp6 jwzJqdfqKB5FRjNV4bne1CuZfr3b6oY3bkup5xPP/+NLZAf1rzgDQMIj6j+vICA/ DpyQ/bLH4LP0l8im59YtrDv73J998VWHH5Ute1WEOnV9OWACnmbkvJ9Tv7/JC1K/ XZ+ilE0QDtCiO11IDcVt0f26/KnsXWaI7CAdgCwGeLm1s3U/rcW9tVdUsTLUcKba UfrSXxSKELU0Z8RAMjjRuwe1rQjpU1RJfoV07Q68co31tPrLtiNttcl5JWSoGDhB Y7/IeSsziyyYq0BlA== Received: from phoenix.codelabs.ru (ppp83-237-105-99.pppoe.mtu-net.ru [83.237.105.99]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1N6V3n-000IH3-92; Fri, 06 Nov 2009 23:05:27 +0300 Date: Sat, 7 Nov 2009 02:05:31 +0300 From: Eygene Ryabinkin To: oss-security@lists.openwall.com Message-ID: References: <0911051520390.27904@mjc.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0911051520390.27904@mjc.redhat.com> Sender: rea-sec@codelabs.ru X-Mailman-Approved-At: Sat, 07 Nov 2009 06:52:35 -0800 Cc: tls@ietf.org, "Steven M. Christey" Subject: Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rea-sec@codelabs.ru List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 11:25:40 -0000 Sorry for jumping in, but I had missed the topic in the other lists, so I am trying to ask here. Also CC'ing tls@ietf.org -- sorry for such cross-posting. Thu, Nov 05, 2009 at 03:24:30PM +0000, Mark J Cox wrote: > Marsh Ray of PhoneFactor has discovered a flaw in the TLS/SSL protocol > related to the handling of the session renegotiations. In certain > circumstances this flaw could be used in MITM attacks, allowing an > attacker to inject attacker-chosen plain text prefix into a secure > session of the victim. Had anyone considered the scenario when the server requires client certificate from the beginning, but MITM possesses some other credentials that will be good for authentication (but can be of no use for authorization)? In this case MITM can use this certificate to start the splitting request, then initiate renegotiation and proxy client's request through the established channel. I see that Apache asks for the certificate for the second renegotiation, as well as the OpenSSL's s_server. Here is the trace for s_server: ----- $ openssl s_client -msg -key userkey.pem -cert usercert.pem -host somehost -port 8443 | grep -E '^(<<<|>>>)' Enter pass phrase for userkey.pem: >>> SSL 2.0 [length 0086], CLIENT-HELLO <<< TLS 1.0 Handshake [length 004a], ServerHello <<< TLS 1.0 Handshake [length 0b01], Certificate depth=1 /C=RU/O=some/CN=CA verify error:num=19:self signed certificate in certificate chain verify return:0 <<< TLS 1.0 Handshake [length 010d], ServerKeyExchange <<< TLS 1.0 Handshake [length 0055], CertificateRequest <<< TLS 1.0 Handshake [length 0004], ServerHelloDone >>> TLS 1.0 Handshake [length 056a], Certificate >>> TLS 1.0 Handshake [length 0046], ClientKeyExchange >>> TLS 1.0 Handshake [length 0086], CertificateVerify >>> TLS 1.0 ChangeCipherSpec [length 0001] >>> TLS 1.0 Handshake [length 0010], Finished <<< TLS 1.0 ChangeCipherSpec [length 0001] <<< TLS 1.0 Handshake [length 0010], Finished R RENEGOTIATING >>> TLS 1.0 Handshake [length 0063], ClientHello <<< TLS 1.0 Handshake [length 0030], ServerHello <<< TLS 1.0 Handshake [length 0b01], Certificate depth=1 /C=RU/O=some/CN=CA verify error:num=19:self signed certificate in certificate chain verify return:0 <<< TLS 1.0 Handshake [length 010d], ServerKeyExchange <<< TLS 1.0 Handshake [length 0055], CertificateRequest <<< TLS 1.0 Handshake [length 0004], ServerHelloDone >>> TLS 1.0 Handshake [length 056a], Certificate >>> TLS 1.0 Handshake [length 0046], ClientKeyExchange >>> TLS 1.0 Handshake [length 0086], CertificateVerify >>> TLS 1.0 ChangeCipherSpec [length 0001] >>> TLS 1.0 Handshake [length 0010], Finished <<< TLS 1.0 Handshake [length 060a]??? <<< TLS 1.0 ChangeCipherSpec [length 0001] <<< TLS 1.0 Handshake [length 0010], Finished ----- If the second certificate is used for the authorization and it is allowed to have distinct certificates during the first and second negotiations, then this could be the other way to trigger this attack against the servers that are requiring certificates from the beginning. Any thoughts? -- Eygene From mike-list@pobox.com Sat Nov 7 08:06:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EB693A69A3 for ; Sat, 7 Nov 2009 08:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 5pJeXr6981Hn for ; Sat, 7 Nov 2009 08:06:42 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id E2A913A692A for ; Sat, 7 Nov 2009 08:06:40 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 74FAB966A3 for ; Sat, 7 Nov 2009 11:07:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=F2/E5isboqCG xxLUzznw7qMejZw=; b=u1jEQlgsZ/Xkmyi1Z8v8vKhQK+ljM0ReiGDhNUGaV7Hs 7+I5BnTyiZvPieFREUCDtpXJFi2BxRfqw30wlO+8KRO6T6qxOZHwTTah7FryvV5H L/XF80MR6cGz9iDb9JSEfkQRuwtTQOKu+c82k8Yc4lRwVTuFqS35D4naYj0h0wA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=SCYQbp kxsFyBHmJZK1x98+05rYkCf9tAcvK6pIItvyfR60/ZsqrpdDN6iKKkbKRVfFJdF0 2lHgQd3NDH9vstw/CLtlmEffGnClT6HVUhEsUgwQlSMqit/LxATeQ2BH79OcqTWu uV60WxMyVYHacF80PZonTNruRAt2LuY4CZ33A= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 71BDE966A2 for ; Sat, 7 Nov 2009 11:07:04 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 898CC966A0 for ; Sat, 7 Nov 2009 11:07:03 -0500 (EST) Message-ID: <4AF59B5E.9010603@pobox.com> Date: Sat, 07 Nov 2009 08:07:58 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AF5112E.2070809@jacaranda.org> In-Reply-To: <4AF5112E.2070809@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 9724D75E-CBB7-11DE-AE49-D595BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 16:06:43 -0000 > Another issue is that a server that supports the extension can refuse > the renegotiation. The current draft is not clear about what the client > and server behaviour should be in that case. > > Suggestion: > > If a ClientHello that is requesting to resume a previous session > contains a Renegotiation_Info extension, and the server supports the > extension but wishes to refuse the renegotiation, it SHOULD reply > with a zero-length Renegotiation_Info. The server already has to reply with an empty Renegotiation_Info extension. That is what happens on an initial handshake even when resuming a previous session, and also for a session_ticket resume. The draft has only a single sentence discussing session resumption: The above rules apply even when TLS resumption is used. Maybe it needs to elaborate more. > If a client that is requesting to resume a session receives a > zero-length Renegotiation_Info without a no_renegotiation alert, it > MUST abort the handshake. If it receives both a zero-length > Renegotiation_Info and a no_renegotiation alert, then the fact that > the Renegotiation_Info contents do not match the previous session's > verify_data values should not be considered a reason for the client > to abort. No, session resumption is no different w.r.t. the Renegotiation_Info extension than a full handshake. The info is always empty on the first handshake for a connection, even when resuming a previous session. As a result, you do not need to store the verify_data from the finished messages in your session cache. > Note that one legitimate reason for refusing a renegotiation is that > the old session has expired, in which case the server is likely to have > forgotten the client and server verify_data values for that session. > Nevertheless it SHOULD reply with a Renegotiation_Info to indicate > that it supports the extension. The server never needs to remember the verify_data from a previous session unless it is the currently active session. When storing a session in your session cache, the verify_data can be discarded since it is not needed in the future. If that session gets resumed later, the Renegotiation_Info will be empty. Mike > For the same reason, when the server refuses a renegotiation it may > not have the ability to check that the contents of the client's > Renegotiation_Info were correct. Therefore, there should be no > requirement for the server to check the contents in that case. From marsh@extendedsubset.com Sat Nov 7 08:23:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C822D3A6A0B for ; Sat, 7 Nov 2009 08:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 HpKMd5fFpYw8 for ; Sat, 7 Nov 2009 08:23:58 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id F1A3C3A69AF for ; Sat, 7 Nov 2009 08:23:57 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6o5O-000HKM-1K; Sat, 07 Nov 2009 16:24:22 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 81493667C; Sat, 7 Nov 2009 16:24:19 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/KW6//bAsn5H2LCv5RMTGF90eIU5ttlu8= Message-ID: <4AF59F32.1030408@extendedsubset.com> Date: Sat, 07 Nov 2009 10:24:18 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rea-sec@codelabs.ru References: <0911051520390.27904@mjc.redhat.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oss-security@lists.openwall.com, tls@ietf.org, "Steven M. Christey" Subject: Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 16:23:58 -0000 Eygene Ryabinkin wrote: > > Had anyone considered the scenario when the server requires client > certificate from the beginning, but MITM possesses some other > credentials that will be good for authentication (but can be of no use > for authorization)? In this case MITM can use this certificate to start > the splitting request, then initiate renegotiation and proxy client's > request through the established channel. Yes. I regret that we didn't get a chance to update the paper before making it generally available, so it is a bit understated: "Other techniques allow the attacker to forward or re-purpose client certificate authentication credentials." > If the second certificate is used for the authorization and it is > allowed to have distinct certificates during the first and second > negotiations, then this could be the other way to trigger this attack > against the servers that are requiring certificates from the beginning. > > Any thoughts? It's even worse than that. In practice, clients will sign with their client cert without user intervention. "For one thing, browsers' behavior of allowing automatic certificate sending is suspect and should be reconsidered. Secondly, browsers suffer from a fundamental inability to authenticate the specific transaction the server is about to execute, ostensibly on behalf of the client. That underlying problem should be addressed, and will likely involve either a protocol change or changes in the way existing protocols are implemented. "Finally, it may make sense to require clients to authenticate servers using the supplied certificate before handing client certificates back to the server. This will effectively prevent the chosen-server attack scenarios described above. This may also represent a breaking protocol change, however, and is being investigated. Even worse (and this is shown in some of the packet captures), web servers will execute MITM's request as soon as they get the Finished message from legit client, but the browser doesn't put up the scary page until he gets the Finished from the server (which could simply be silently dropped by the MITM). So if a client has useful client cert (or smart card) credentials, MITM can redirect a request to a server of his choosing that will accept them, use them to authenticate his arbitrary transaction, and the browser may never even show the scary cert error page. - Marsh From mike-list@pobox.com Sat Nov 7 08:58:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AB53A68C9 for ; Sat, 7 Nov 2009 08:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 ddBDWdX9BMvv for ; Sat, 7 Nov 2009 08:58:15 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 4580D3A67A6 for ; Sat, 7 Nov 2009 08:58:14 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 22EDF774CC for ; Sat, 7 Nov 2009 11:58:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=JNsDS6d99sbi TsJ4DjFRqvMtnUU=; b=RNeE0i5hpedTG3Rzn2t0vYxJmh7Opx+pQesbPoNURhOR T6cOpzGan6Br3gKlKjHHkY+a3vY8gWvIYb4eZ2vHEmASVcxqR0KPVyACr1TbkJEs uNulX3fHbCZz7ZhO/r1hmcc0/Fg8HzcslTIs7lidXAPHPHs3Z6/kn2UFF+K/InY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=G4vVrw /Z4qU2A7+2VFIWGXqDXfwjlpOXa48gmjPh2jbJdlOl87yCZj0y3wGdbTzKwABtdz ZsoaDvYXwJQelXirtsJFB1BfgE7rL4b4jCk1fMg9T8WJSWsDuwRRL3gVUmqamd/2 JurrUsMx0LGG5MszEtQrReBUjzq9m5GSqpZAk= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 205C5774CB for ; Sat, 7 Nov 2009 11:58:38 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C92DA774CA for ; Sat, 7 Nov 2009 11:58:37 -0500 (EST) Message-ID: <4AF5A774.8070002@pobox.com> Date: Sat, 07 Nov 2009 08:59:32 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <82aaz0rf1m.fsf@mid.bfk.de> In-Reply-To: <82aaz0rf1m.fsf@mid.bfk.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CB32BCC6-CBBE-11DE-9108-7C40EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 16:58:16 -0000 > Therefore, I think a protocol change is less invasive (assuming that > it is essentially free-for-all-uses IPR-wise). Is there any issue with IPR? Mike From marsh@extendedsubset.com Sat Nov 7 09:18:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32563A6916 for ; Sat, 7 Nov 2009 09:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 6olb4BNpcyOM for ; Sat, 7 Nov 2009 09:18:25 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 36FA53A6900 for ; Sat, 7 Nov 2009 09:18:25 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6ow5-00030K-CG; Sat, 07 Nov 2009 17:18:49 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 74B4F667C; Sat, 7 Nov 2009 17:18:48 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+i0VAzpKgBEqzxmP9k3tcW/OMQOObUaCk= Message-ID: <4AF5ABF7.2010706@extendedsubset.com> Date: Sat, 07 Nov 2009 11:18:47 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <82aaz0rf1m.fsf@mid.bfk.de> <4AF5A774.8070002@pobox.com> In-Reply-To: <4AF5A774.8070002@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 17:18:26 -0000 Michael D'Errico wrote: >> Therefore, I think a protocol change is less invasive (assuming that >> it is essentially free-for-all-uses IPR-wise). > > Is there any issue with IPR? It is my opinion that it is difficult to prove a negative statement, but: * The proposed protocol extension is dirt-simple, possibly minimal even. * The method used is similar to the public work on the channel bindings (binding TLS session based on Finished message data). * At the Sept 29 meeting, this same idea was proposed by several people simultaneously. * At the Sept 29 meeting, we made a clear statement of the expectation for vendors to disclose any IP they thought might cover this. None presented any. - Marsh From mike-list@pobox.com Sat Nov 7 09:51:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893EB3A68AF for ; Sat, 7 Nov 2009 09:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 mtDxuDquPnQT for ; Sat, 7 Nov 2009 09:51:28 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 8D37D3A688D for ; Sat, 7 Nov 2009 09:51:28 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BF0DF77851 for ; Sat, 7 Nov 2009 12:51:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rePPLpZrzBBV JirdNxLreYcRArU=; b=GnkqHsvPL/mdv9X1oG3SdnOrYvcXmPlvIAedxMOXKmju 2z/5kYXIfsEVnpAfGSykm9UdooWdNboGcAeEaSiBaDknedyWX/hqPRXq+zwT3woH iYpazjOnWF8Q5vQF8uH5Pmv8wmmwDnDj8tTWXTH+gh+qn5vLmyxz2afCcckuNdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=vYh25T fi6wY7BRIrtODHHgV/OohsulD2rQFjYW+HFGMZaUWY5n5LTkwekzZ5gfePAAbngN p+8/DMepvxFtKla0+2A9Jla9ObzHM7hWAkIA8ScSYysZ/K/jQD7wFqn7okx1x2GF 3bjmn/I8lcnfFh1es4DH3Rw3ql/3EGWEgPdUM= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BBB7977850 for ; Sat, 7 Nov 2009 12:51:52 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 44FB27784E for ; Sat, 7 Nov 2009 12:51:52 -0500 (EST) Message-ID: <4AF5B3EF.9020709@pobox.com> Date: Sat, 07 Nov 2009 09:52:47 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp> <4AF52966.3070400@gnutls.org> <4AF53027.6030701@extendedsubset.com> In-Reply-To: <4AF53027.6030701@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 3B59E626-CBC6-11DE-B52F-7C40EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 17:51:29 -0000 Marsh Ray wrote: > Nikos Mavrogiannopoulos wrote: >> the application layer >> cannot distinguish between the two sessions (one before renegotiation, >> one after). The problem was for me that you could receive any amount of >> application data even after a rehandshake was requested, thus I had to >> cache them and present to the application after rehandshake was finished. > > Yes, yes! > > The buffered stream IO model we all take for granted is insufficient to > represent the semantics of a TLS connection in the presence of > renegotiation! My server works a bit differently; it does what I'll call "lazy renegotiation." If it receives a ClientHello for a renegotiation, it calculates all of the response handshake messages and puts them into the outbound queue for delivery to the client. It will happily continue sending application data to the client and also receiving and passing application data back to the application while the pending TLS session is in this uncompleted state. I believe this is what the TLS spec intended. If the client continues with the handshake, those messages are processed as they are received, and the pending TLS session moves closer to completion. It is possible for the client and/or server to end up with two different active sessions -- one based on the renegotiation, and one based on the original handshake. This would happen if one side fails to send a ChangeCipherSpec and Finished message. So the question becomes: should this be a legal state to be in? I could add some logic to disallow the sending of application data over a newly- installed renegotiated session until the peer has completed its side of the handshake. But it should probably be allowed to continue receiving application data over the old session since it could have been in transit prior to sending the Finished message. I think a good addition to my API would be to have a callback that tells the application when a renegotiation has completed, and to also pass back any application data that was received under the old session, but not yet read by the application. There is another weird possibility that should probably be prohibited: if for some reason a ChangeCipherSpec is received during a renegotiation, but not followed immediately by a Finished message, the receipt of any application data should cause a handshake failure. Mike > Even with an added callback for cert validation, ambiguities linger! > > I think it highly probable that real vulnerabilities exist in > applications due to this mismatch. > > The draft-rescorla-tls-renegotiate extension should help quite a bit though. > > - Marsh From mike-list@pobox.com Sat Nov 7 13:59:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657003A6887 for ; Sat, 7 Nov 2009 13:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 biUNK20TPhEv for ; Sat, 7 Nov 2009 13:59:33 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 6EC183A67B6 for ; Sat, 7 Nov 2009 13:59:32 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D5A2B786DF for ; Sat, 7 Nov 2009 16:59:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=venAg3M4Xyt0 rk6gGxtogWJR1lY=; b=xUSR0+tVwE75l7KBjkjPB1TVujPRavLQO7p7O2qChDA/ ybuEdl+VlTDdeHyrsmiDB1CvYS72T+3lmThTU8/jfK5NK3tZavEhmhqOiX1BqZbI FkUL9skX0YKXKnY6Ic60EzPd5ibPL7lwUcjWRQLdtOhXDu60Iub51jiOSLeKrF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=pwN0Mi Lx9XXhOy1w7m74bFIiWTZRjO548z9Ff/AMLV+IFZHOzEx5osyrjiCD+fLarCrDF/ H+ODj/HY3Su5+enCB1RZndg6TU+M7D7oJchgMSj7SRUIH6fajk+U3ZeYi/BRlnAy MS5Hy4291Mzxsfq4lrqgFCJL9h2b2Y9ZCH38w= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D1865786DE for ; Sat, 7 Nov 2009 16:59:55 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 76977786DD for ; Sat, 7 Nov 2009 16:59:55 -0500 (EST) Message-ID: <4AF5EE11.5030007@pobox.com> Date: Sat, 07 Nov 2009 14:00:49 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E25C831C-CBE8-11DE-8BA6-7C40EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Test Server (was TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 21:59:34 -0000 > Does anyone have a public testserver up and running yet? You can test against https://www.mikestoolbox.net or .org If you run into problems, you can contact me off list at mikestoolbox at pobox-dot-com. Mike From mike-list@pobox.com Sat Nov 7 14:16:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395AC3A6826 for ; Sat, 7 Nov 2009 14:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Jm5rYSBdASoi for ; Sat, 7 Nov 2009 14:16:58 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 6B5F83A68A0 for ; Sat, 7 Nov 2009 14:16:58 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 34447787E6 for ; Sat, 7 Nov 2009 17:17:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=k3g3CG/URx3C 8IKtRUPrs0IfTPY=; b=Gg0jN/zGPmKuBe4DxkECQJxuzf3pQa9EsQxbFC8bj7ag x0EWrnvfbEs9lDjg2t1hmolfmxbOkXXAOGtW1hmNNglAE0Q0GSH/FVhfR8stcsGf HQWHQ7RJsEcMmu5DrVtrmvNIyHMd2Gvqidf/ptV4y6bkJOiRTq+s0RxYMv6V274= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=tWRhzv KX10oZ4JpjmB3fJkvnvy0hOy9yj/Hg7lQYaZXF3qsjEuA1p8g4GAs/6B0N7jlhJ6 zm4RE1xGSTqJMexD4ANr/Pt/MScBVtzFDMTP5AN6Re/v+qjiqmpmt98i7MW6X2Wa B90oQTbpqMS0/e/DlZC18g/EZYuuxsKoHwC8Q= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 30A88787E5 for ; Sat, 7 Nov 2009 17:17:23 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id CDF73787E4 for ; Sat, 7 Nov 2009 17:17:22 -0500 (EST) Message-ID: <4AF5F22B.9020407@pobox.com> Date: Sat, 07 Nov 2009 14:18:19 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF5EE11.5030007@pobox.com> In-Reply-To: <4AF5EE11.5030007@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 52A0C924-CBEB-11DE-B671-7C40EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Test Server (was TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 22:16:59 -0000 > You can test against https://www.mikestoolbox.net or .org I forgot to mention that in order to successfully renegotiate, you will need to do it before sending the blank line that ends the HTTP request. This is because my server is not really an HTTP server; it just spits out a diagnostic page after reading the request. The diagnostics will be of the last session negotiated. Mike From djhopwood@googlemail.com Sat Nov 7 16:03:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E3A3A6823 for ; Sat, 7 Nov 2009 16:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 zFaC4-SJQYiX for ; Sat, 7 Nov 2009 16:03:11 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id DDC2A3A6809 for ; Sat, 7 Nov 2009 16:03:10 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so495259eya.51 for ; Sat, 07 Nov 2009 16:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=exLzplEfs75wCiIJwnzmaIEAG8jIC+YakOE4vNLWwGA=; b=KQaayFtN08GgXbF5TR1BFGczT1UsN2VyXgvi4V3aH/cpmJtPE6vixrpoz7Uym1vsl+ /ST7OkwGyg4u5BjjJa7eAwBTE1tAtPH9wTr9LpihAotUWfxUG2xyeuC7fhGvMOcL2+zl KUC67MEUK0Wh9+2uG+EMvbKAhvJRYMR1ab2+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=o5+7MEONZK1nDJFrCXx/K+Fi+yPZkSpMP1wpkdpc9DZX12rNA/oYxV69IsRDe5Mm8H exmDm5KYTfgkIgm5h3Ehkm+UukjQe7zlEs1vq/wsgFBN6qTq6Hurc7YPOynsJsMQ8dCl tSt15Pm025AQyHsA50UVBz/iQxGISNivLb+9o= Received: by 10.213.0.196 with SMTP id 4mr5814267ebc.41.1257638606749; Sat, 07 Nov 2009 16:03:26 -0800 (PST) Received: from ?192.168.0.2? (5e025226.bb.sky.com [94.2.82.38]) by mx.google.com with ESMTPS id 5sm2291541eyf.47.2009.11.07.16.03.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Nov 2009 16:03:26 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF60AC6.4000803@jacaranda.org> Date: Sun, 08 Nov 2009 00:03:18 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AF5112E.2070809@jacaranda.org> <4AF59B5E.9010603@pobox.com> In-Reply-To: <4AF59B5E.9010603@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigDD34A895DF010F37BB68206C" Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 00:03:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDD34A895DF010F37BB68206C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: >> Another issue is that a server that supports the extension can refuse >> the renegotiation. The current draft is not clear about what the clien= t >> and server behaviour should be in that case. >> >> Suggestion: >> >> If a ClientHello that is requesting to resume a previous session >> contains a Renegotiation_Info extension, and the server supports the >> extension but wishes to refuse the renegotiation, it SHOULD reply >> with a zero-length Renegotiation_Info. >=20 > The server already has to reply with an empty Renegotiation_Info > extension. That is what happens on an initial handshake even when > resuming a previous session, and also for a session_ticket resume. [...] > No, session resumption is no different w.r.t. the Renegotiation_Info > extension than a full handshake. The info is always empty on the > first handshake for a connection, even when resuming a previous session= =2E >=20 > As a result, you do not need to store the verify_data from the finished= > messages in your session cache. Yes, you're right. I was confused. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigDD34A895DF010F37BB68206C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr2CtIACgkQWUc8YzyzqAcNdAEAjzaoGYSlEqjJVE1LaXwiC+fC GB+FBqqdvi1J3A0wyb0A/2irbHtCtaqtgpsb8/Mq4MGgknjW33A33Y3kUGK+jjLl =0wvP -----END PGP SIGNATURE----- --------------enigDD34A895DF010F37BB68206C-- From uri@ll.mit.edu Sat Nov 7 17:18:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5A13A68ED for ; Sat, 7 Nov 2009 17:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuXhnYTBaFqQ for ; Sat, 7 Nov 2009 17:18:34 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 1A7CF3A68E3 for ; Sat, 7 Nov 2009 17:18:33 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nA81Isoi027045; Sat, 7 Nov 2009 20:18:54 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAUlaOVZ; Sat Nov 7 20:16:56 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Sat, 7 Nov 2009 20:16:56 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'Nicolas.Williams@sun.com'" , "'ietfdbh@comcast.net'" Date: Sat, 7 Nov 2009 20:16:30 -0500 Thread-Topic: To API or not (Re: [TLS] TLS renegotiation issue) Thread-Index: AcpfOvD9Mps59JgvQYCb7MxLqJIBpgA1jjTm Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3C7@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] To API or not (Re: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 01:18:35 -0000 SUVURiBjYW4ndCB3cml0ZSBwcmVjaXNlIEFQSSBiZWNhdXNlIHRob3NlIGFyZSBhcHBsaWNhdGlv bi1zcGVjaWZpYy4gSUVURiBjYW4gYW5kIG9mdGVuIHNob3VsZCB3cml0ZSBBYnN0cmFjdCBTZXJ2 aWNlIEludGVyZmFjZSAoQVNJKSBzcGVjcyB0aGF0IGRlZmluZSB0aGUgbWluaW1hbCBhbW91bnQg b2YgZGF0YSB0aGF0IG9uZSBjb21wb25lbnQgbmVlZHMgZnJvbSBhbm90aGVyIG9uZSB0byBiZSBv ZiB1c2UgdG8gaXQuDQoNClRydWUsIEFTSSBpcyBubyBwYW5hY2VhLiBCdXQgKGFzIElNSE8gU05N UHYzIGV4cGVyaWVuY2UgcHJvdmVkKSBpdCBiZW5lZml0cyBtdWNoIG1wcmUgdGhhbiBpdCBpbmNv bnZlbmllbmNlcy4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBOaWNv bGFzIFdpbGxpYW1zIDxOaWNvbGFzLldpbGxpYW1zQHN1bi5jb20+DQpUbzogRGF2aWQgSGFycmlu Z3RvbiA8aWV0ZmRiaEBjb21jYXN0Lm5ldD4NCkNjOiBCbHVtZW50aGFsLCBVcmkgLSAwNjYyIC0g TUlUTEw7ICdNYXJzaCBSYXknIDxtYXJzaEBleHRlbmRlZHN1YnNldC5jb20+OyB0bHNAaWV0Zi5v cmcgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IEZyaSBOb3YgMDYgMTg6MDk6NDEgMjAwOQpTdWJqZWN0 OiBUbyBBUEkgb3Igbm90IChSZTogW1RMU10gVExTIHJlbmVnb3RpYXRpb24gaXNzdWUpDQoNCk9u IFNhdCwgTm92IDA3LCAyMDA5IGF0IDA2OjM5OjQ4QU0gKzA4MDAsIERhdmlkIEhhcnJpbmd0b24g d3JvdGU6DQoNCk9mIGNvdXJzZSwgdGhlIGlzc3VlIGhlcmUgaXMgbm90ICJtdXN0IHRoZSBJRVRG IHByb3ZpZGUgQVBJcz8iIGJ1dCAiY2FuDQp0aGUgSUVURiBwcm92aWRlIEFQSXM/Ii4gIFRoZSBh bnN3ZXIgdG8gdGhhdCBpcyBhIHJlc291bmRpbmcgInllcyIuDQoNCj4gSSB3YXMgcHJvYmFibHkg dGhlIHN0cm9uZ2VzdCBwcm9wb25lbnQgb2YgdXNpbmcgYWJzdHJhY3QgQVBJcw0KPiAoYWN0dWFs bHkgQVNJcyAtIGFic3RyYWN0IHNlcnZpY2UgaW50ZXJmYWNlcykgdG8gZGVwaWN0IGRhdGEgZmxv d3MNCj4gYmV0d2VlbiBwYXJ0cyBvZiB0aGUgc3lzdGVtLiANCj4gDQo+IExldCBtZSBvYnNlcnZl IHRoYXQgdGhvc2UgQVNJcyBoYXZlIG1hZGUgaXQgYWxtb3N0IGltcG9zc2libGUgdG8NCj4gdXBk YXRlIHRoZSBwaWVjZXMgb2YgU05NUHYzLCBiZWNhdXNlIHRoZSBBU0lzIGFjdCBhcyBkZXNpZ24N Cj4gY29uc3RyYWludHMuIFRoZSBzdHJvbmcgYXJjaGl0ZWN0dXJhbCBtb2RlbCBtYWRlIGl0IHZl cnkgZGlmZmljdWx0IHRvDQo+IHVwZGF0ZSB0aGUgU01JIHdpdGhvdXQgZm9yY2luZyBjaGFuZ2Vz IHRvIHRoZSBBU0lzLiBUaGUgc3Ryb25nDQo+IGFyY2hpdGVjdHVyYWwgbW9kZWwgbWFkZSBpdCB2 ZXJ5IGRpZmZpY3VsdCB0byB1cGRhdGUgdGhlIG9wZXJhdGlvbnMNCg0KSSBjb25zaWRlciB0aGlz IGEgZmVhdHVyZS4gIE5vdCB0aGF0IEkgd2FudCB0byBzbG93IGRvd24gZGV2ZWxvcG1lbnQsDQpt aW5kIHlvdS4gIE5vciB0aGF0IEkgd2FudCB0byBzdGF5IHdlZGRlZCB0byBhbiBBU0kgYXJjaGl0 ZWN0dXJlIHRoYXQNCnR1cm5zIG91dCB0byBiZSByZXNpc3RhbnQgdG8gdXNlZnVsZSBjaGFuZ2Vz LiAgUmF0aGVyLCBjaGFuZ2VzIHRvIHRoZQ0KcHJvdG9jb2wgc2hvdWxkIGVpdGhlciBiZSBtaW5k ZnVsIG9mIHRoZSBhYnN0cmFjdCBpbnRlcmZhY2VzIHRoYXQgaGF2ZQ0KYmVlbiBzcGVjaWZpZWQg KGkuZS4sIHRoZSBleGlzdGluZyBpbnRlcmZhY2VzLCBwb3NzaWJseSB3aXRoIGV4dGVuc2lvbnMs DQpzaG91bGQgY29udGludWUgdG8gd29yayksIG9yIHRoZXkgc2hvdWxkIGludHJvZHVjZSBhIHJl cGxhY2VtZW50IHNldCBvZg0KaW50ZXJmYWNlcy4NCg0KPiBzZXQgb2YgdGhlIFNOTVAgcHJvdG9j b2wuIEJvdGggb2YgdGhlc2UgZWZmb3J0cyByZXN1bHRlZCBpbiBmYWlsZWQNCj4gV0dzLiBBZGRp bmcgc3VwcG9ydCBmb3IgZXhpc3RpbmcgU1NIIHNlY3VyaXR5IGluZnJhc3RydWN0dXJlIHRvb2sN Cj4gdGhyZWUgZG9jdW1lbnRzIGJlY2F1c2Ugd2UgaGFkICB0byBtb2RpZnkgdGhlIGFyY2hpdGVj dHVyZSwgaW5jbHVkaW5nDQo+IGFsbCB0aGUgYWZmZWN0ZWQgQVNJcy4gV2hhdCBtaWdodCBoYXZl IHRha2VuIG1vbnRocyB0byBjb21wbGV0ZSB0b29rDQo+IHllYXJzIC0gbGFyZ2VseSBiZWNhdXNl IG9mIHRoZSB1c2Ugb2YgQVNJcyBpbiB0aGUgYXJjaGl0ZWN0dXJlLg0KDQpJZiB0aGUgQVNJcyBt YWRlIGl0IHRvbyBoYXJkIHRvIGNoYW5nZSB0aGUgcHJvdG9jb2wgaW4gdXNlZnVsIHdheXMsIHRo ZW4NCnRoZSBBU0lzIHNob3VsZCBiZSByZXBsYWNlZC4NCg0KPiBNYW55IG9mIHRoZSBwZW9wbGUg d2hvIHdvcmtlZCBkZXZlbG9wZWQgTmV0Y29uZiB3ZXJlIGludm9sdmVkIGluIHRoZQ0KPiBTTk1Q djMgYXJjaGl0ZWN0dXJlIGVmZm9ydCwgYW5kIHN1YnNlcXVlbnQgdXBkYXRlcy4gTG9vayBhdCB0 aGUNCj4gTmV0Y29uZiBhcmNoaXRlY3VyYWwgbW9kZWwgLSBpdCB1c2VzIHZlcnkgc2ltcGxlLCB2 ZXJ5IG5lYnVsb3VzDQo+IGxheWVyaW5nIGFzIHRoZSBib3JkZXJzIGJldHdlZW4gcG9ydGlvbnMs IG5vdCBBU0lzLiBUaGlzIGlzIGENCj4gZHJhbWF0aWNhbGx5IHNpbXBsZXIgYW5kIGVhc2llciBh cHByb2FjaCB0byB3b3JrIHdpdGguDQoNCkkgYWdyZWUgdGhhdCBpdCBpcyBkcmFtYXRpY2FsbHkg c2ltcGxlciB0byB3cml0ZSBzdWNoIGRvY3VtZW50cy4gIEkNCmRvbid0IGFncmVlIHRoYXQgdGhl IHJlc3VsdCBpcyBuZWNlc3NhcmlseSBiZXR0ZXIuICBUaGVyZSdzIGEgd2hvbGUNCmNvbnRpbnV1 bSBvZiBkZWdyZWUgb2YgZm9ybWFsaXNtIHRoYXQgd2UgY2FuIHVzZSBpbiBvdXIgZG9jdW1lbnRz LiAgV2hhdA0KZGVncmVlIG9mIGZvcm1hbGlzbSBpcyBiZXN0IHdpbGwgZGVwZW5kIG9uIGNvbnRl eHQgKGluY2x1ZGluZyB3aG8gdGhlDQpkb2N1bWVudCBhdXRob3JzIGFuZCBpbXBsZW1lbnRvcnMg YXJlKS4gIFRoZXJlIHdpbGwgYmUgY29udGV4dHMgd2hlcmUNCnVzaW5nIFhNTCBzY2hlbWFzIGlz IHVzZWZ1bCwgYW5kIG9uZXMgd2hlcmUgdGhhdCB3b3VsZCBiZSBvdmVya2lsbCwgZm9yDQpleGFt cGxlOyByZXBsYWNlIFhNTCB3aXRoIEFTTi4xL1NETC93aGF0ZXZlci4gIFRoZXJlIGFyZSBjb250 ZXh0cyB3aGVyZQ0KeW91IHdhbnQgdG8gdXNlIHBzZXVkby1jb2RlLCBvciBldmVuIGFjdHVhbCBz b3VyY2UgY29kZSB0byBkZXNjcmliZSBhcw0KZm9ybWFsbHkgYXMgcG9zc2libGUsIHdoYXQgbXVz dCBiZSBkb25lLCB3aGlsZSBpbiBvdGhlciBjb250ZXh0cyAidGVzdA0KdmVjdG9ycyIsIG9yIGp1 c3QgcGxhaW4gRW5nbGlzaCBsYW5ndWFnZSBwcm9zZSB3aWxsIGRvLg0KDQpJIHRoaW5rIHRoYXQg YWJzdHJhY3QgaW50ZXJmYWNlcyB3b3VsZCBiZSB1c2VmdWwgZm9yIFRMUy4gIE1vc3Qgd291bGQN CnByb2JhYmx5IGRpc2FncmVlLiAgSWYgc29tZWRheSBJIGdldCB0byBiZSBhIFRMUyBpbXBsZW1l bnRvciwgSSBtYXkgd2VsbA0Kc3VibWl0IGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiBJLUQgZGVz Y3JpYmluZyBhbiBhYnN0cmFjdCBUTFMgQVBJLCBhbmQNCm1heWJlIHRoZW4gSSBjYW4gY29udmlu Y2UgdGhlIHJlc3QuICBVbnRpbCB0aGVuIEknbSBoYXBweSB0byBiZSBpbiB0aGUNCm1pbm9yaXR5 LCB3aXRoIHNvbWUgbWlub3IgZXhjZXB0aW9uczogSSB0aGluayBpdCdzIGltcG9ydGFudCBmb3J0 aGUgYmFzZQ0KVExTIHNwZWMgdG8gc3BlYWsgb2YgVExTIGNvbm5lY3Rpb25zLCBjaGFubmVsIGJp bmRpbmdzIGZvciBUTFMNCmNvbm5lY3Rpb25zLCBhbmQgY2hhbm5lbCBiaW5kaW5nIHRvIFRMUyBj b25uZWN0aW9ucy4NCg0KPiBJIHN0cm9uZ2x5IGFkdmlzZSB5b3UgdG8gYmUgY2FyZWZ1bCB3aGF0 IHlvdSB3aXNoIGZvci4gDQoNClRoYW5rcy4NCg0KTmljbw0KLS0gDQo= From marsh@extendedsubset.com Sat Nov 7 17:41:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8A33A689A for ; Sat, 7 Nov 2009 17:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 SiLg2Boka5p4 for ; Sat, 7 Nov 2009 17:41:49 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id A1C1B3A6918 for ; Sat, 7 Nov 2009 17:41:49 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N6wnG-00007P-3Y for tls@ietf.org; Sun, 08 Nov 2009 01:42:14 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 36B17667C for ; Sun, 8 Nov 2009 01:42:12 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18QtrNStgF2WAFMMiaCUWuWdiIaujIO/Ow= Message-ID: <4AF621F2.80403@extendedsubset.com> Date: Sat, 07 Nov 2009 19:42:10 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "'tls@ietf.org'" References: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3C7@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3C7@LLE2K7-BE01.mitll.ad.local> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] To API or not (Re: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 01:41:50 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > IETF can't write precise API because those are application-specific. s/can't/shouldn't/ ? It bugs me the way w3c goes as far as specifying that some APIs must use UTF-16 host-endian for their string representation, even for things usually accessed from scripting languages. > I think that abstract interfaces would be useful for TLS. I agree. Somebody would have noticed that they were adding a new layer to the model, and it would have forced an interface change which either would have been rejected or documented properly. - Marsh From pgut001@wintermute01.cs.auckland.ac.nz Sun Nov 8 00:42:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A1728C0EF for ; Sun, 8 Nov 2009 00:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.346 X-Spam-Level: X-Spam-Status: No, score=-4.346 tagged_above=-999 required=5 tests=[AWL=-1.747, 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 yxssn2-BUxGG for ; Sun, 8 Nov 2009 00:42:36 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 562973A689B for ; Sun, 8 Nov 2009 00:42:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 143F49CEF7; Sun, 8 Nov 2009 21:42:45 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No8hGFkY4Jmb; Sun, 8 Nov 2009 21:42:44 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B2ECD9CEEF; Sun, 8 Nov 2009 21:42:38 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N73M6-0004E8-Gw; Sun, 08 Nov 2009 21:42:38 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1N73M6-0002z0-5Y; Sun, 08 Nov 2009 21:42:38 +1300 From: Peter Gutmann To: marsh@extendedsubset.com, rea-sec@codelabs.ru In-Reply-To: <4AF59F32.1030408@extendedsubset.com> Message-Id: Sender: pgut001 Date: Sun, 08 Nov 2009 21:42:38 +1300 Cc: oss-security@lists.openwall.com, tls@ietf.org, coley@linus.mitre.org Subject: Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 08:42:37 -0000 Marsh Ray writes: >For one thing, browsers' behavior of allowing automatic certificate sending >is suspect and should be reconsidered. It's not actually safe to reconsider this because many servers (including some at very large sites) always request client auth, often without the site admins being aware of this or knowing how to disable it. I became aware of this when I changed my code to add a roadblock until the user explicitly responded to a client cert request, leading to many complaints about sites that formerly "worked" and now didn't (I've found all sorts of other broken behaviour around client-auth, for example servers that send a list of 150-odd CAs, every one they know of, as an indication of who they'll accept certs from, and other strangeness). Disabling the automatic sending of client certs would therefore obviously break, to the client, a number of (what I consider) broken servers. What my code currently does is: if( cert request received ) if( client cert present ) send cert; else send no-cert alert; This isn't totally safe though because there's no "tell user to make their cert available" option if they haven't pre-emptively done so, it "works" mostly because the extreme rarity of client cert use and stereotyped behaviour of existing clients hides all the glitches in implementations. Peter. From benl@google.com Sun Nov 8 09:35:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0433A68F4 for ; Sun, 8 Nov 2009 09:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 hHImxWr+HBKX for ; Sun, 8 Nov 2009 09:35:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id BBA373A6825 for ; Sun, 8 Nov 2009 09:35:07 -0800 (PST) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id nA8HZWHi020695 for ; Sun, 8 Nov 2009 09:35:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257701733; bh=yUQ3sk23iNQ2LejsAWwy+Mznmlg=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=i5b4RUeEHP3ZOoTqGwn6OucAsILlpHpeuJO77EdoQgwFH9slqb9AHxKdAYcIwTTSX 5MCe+P2oIh0+iNfcj4qzw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=Mfys6qmERl0PAF7HUIystzjJnApBRXhYsjfmtxHPR5RX/XjPDUeDatdRcHG3xgtek yPqGDp33AnwZ2ZGvuDJRw== Received: from qw-out-1920.google.com (qwc5.prod.google.com [10.241.193.133]) by zps38.corp.google.com with ESMTP id nA8HZTVX020041 for ; Sun, 8 Nov 2009 09:35:30 -0800 Received: by qw-out-1920.google.com with SMTP id 5so521919qwc.58 for ; Sun, 08 Nov 2009 09:35:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.119.7 with SMTP id x7mr913765qcq.22.1257701729480; Sun, 08 Nov 2009 09:35:29 -0800 (PST) Date: Sun, 8 Nov 2009 17:35:29 +0000 Message-ID: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> From: Ben Laurie To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 17:35:08 -0000 I have just committed an implementation of https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt to the head of the 0.9.8-stable tree of OpenSSL. At some point soon, I guess we'll be releasing an update. It'd be good not to consume an experimental extension number in the process - how do we get a real one allocated? From ngm@google.com Sun Nov 8 12:51:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102C93A683A for ; Sun, 8 Nov 2009 12:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 6N1x2-7uzCQ1 for ; Sun, 8 Nov 2009 12:51:39 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id E4A843A6768 for ; Sun, 8 Nov 2009 12:51:38 -0800 (PST) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id nA8Kq3nJ011362 for ; Sun, 8 Nov 2009 12:52:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257713524; bh=LOvOmtWslRi1N9yn9VnpW9zAG6o=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Nuyomirm3vSBhtOISW53qorT5EvzIsA5yfoABMLhefTQhEbOcWZyrkcuJDVQqmiaq 8anwl3fpb2VcnXthMBNnw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=uxwqsjYnSp+tB3ZH63q5Upr/3qFAUJEyPNwb58X2Unct5LLxSIpJwSYRX0S0b4hdR 0D7KkdZsWzQ8rmqc68OxQ== Received: from pxi26 (pxi26.prod.google.com [10.243.27.26]) by spaceape11.eur.corp.google.com with ESMTP id nA8Kpwao024445 for ; Sun, 8 Nov 2009 12:52:00 -0800 Received: by pxi26 with SMTP id 26so1508655pxi.21 for ; Sun, 08 Nov 2009 12:51:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.7.10 with SMTP id 10mr743836wfg.137.1257713518546; Sun, 08 Nov 2009 12:51:58 -0800 (PST) In-Reply-To: References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Date: Sun, 8 Nov 2009 12:51:58 -0800 Message-ID: <28425e380911081251j48a1065fv98e782aecf9f7ffc@mail.gmail.com> From: Nagendra Modadugu To: Eric Rescorla Content-Type: multipart/alternative; boundary=00504502aca58091d40477e23f79 X-System-Of-Record: true Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 20:51:40 -0000 --00504502aca58091d40477e23f79 Content-Type: text/plain; charset=ISO-8859-1 SSL3 is still in wide use since it is not considered insecure (other than the renegotiation issue). Is it feasible to explicitly deprecate SSL3? Or state that renegotiation support for SSL3 is deprecated? Here is the rationale. Clients that have both SSL3/TLS1 enabled will send a 'mixed-type' SSL3/TLS1 ClientHello (i.e. Record.version = 3.0, ClientHello.version = 3.1). Such clients should, strictly speaking, not include TLS extensions, which means that renegotiation should not be allowed by the server regardless of the protocol version negotiated. Considering that a majority of clients will continue to support both SSL3 and TLS1 for some time (as a practical matter), the new extension will not come into effect unless clients (a) cease sending mixed-type ClientHello messages, or (b) send TLS extensions even when Record.version = 3.0. Option (a) leaves open the possibility for down-grade attacks (i.e. a MITM blocks TLS1 connections, allowing clients to reconnect over SSL3 -- I recall that atleast one major browser will attempt to reconnect over SSL3 if a TLS1, or mixed-type handshake fails). Option (b) requires extension support to be "back-ported" to SSL3. I suggest that the draft discourage the use of SSL3 entirely. On Thu, Nov 5, 2009 at 10:16 AM, Eric Rescorla wrote: > I now have a draft extension up at: > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml > > Comments welcome. > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00504502aca58091d40477e23f79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
SSL3 is still in wide use since it is not considered insecure (other th= an the renegotiation issue). =A0Is it feasible to explicitly deprecate SSL3= ? =A0Or state that renegotiation support for SSL3 is deprecated?

Her= e is the rationale.=A0 Clients that have both SSL3/TLS1 enabled will send a= 'mixed-type' SSL3/TLS1 ClientHello (i.e. Record.version =3D 3.0, C= lientHello.version =3D 3.1). =A0Such clients should, strictly speaking, not= include TLS extensions, which means that renegotiation should not be allow= ed by the server regardless of the protocol version negotiated. =A0Consider= ing that a majority of clients will continue to support both SSL3 and TLS1 = for some time (as a practical matter), the new extension will not come into= effect unless clients (a) cease sending mixed-type ClientHello messages, o= r (b) send TLS extensions even when Record.version =3D 3.0.=A0

Option (a) leaves open the possibility for down-grade attacks (i.e. a M= ITM blocks TLS1 connections, allowing clients to reconnect over SSL3 -- I r= ecall that atleast one major browser will attempt to reconnect over SSL3 if= a TLS1, or mixed-type handshake fails).=A0 Option (b) requires extension s= upport to be "back-ported" to SSL3.

I suggest that the draft discourage the use of SSL3 entirely.

On= Thu, Nov 5, 2009 at 10:16 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> I now have a draft extension up a= t:
>
> https://svn.resiprocate.org/rep/ietf-draft= s/ekr/draft-rescorla-tls-renegotiate.txt
> ht= tps://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiat= e.xml
>
> Comments welcome.
>
> -Ekr
> _______________= ________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls<= br> >

--00504502aca58091d40477e23f79-- From paul.hoffman@vpnc.org Sun Nov 8 13:18:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68B93A697D for ; Sun, 8 Nov 2009 13:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.302 X-Spam-Level: X-Spam-Status: No, score=-5.302 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 jBNM26aP5cOL for ; Sun, 8 Nov 2009 13:18:45 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D0D7E3A6976 for ; Sun, 8 Nov 2009 13:18:45 -0800 (PST) Received: from [133.93.128.35] (host-128-35.meeting.ietf.org [133.93.128.35]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nA8LJ5pp002445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2009 14:19:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> Date: Mon, 9 Nov 2009 06:19:03 +0900 To: Ben Laurie , tls@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 21:18:46 -0000 At 5:35 PM +0000 11/8/09, Ben Laurie wrote: >At some point soon, I guess we'll be releasing an update. It'd be good >not to consume an experimental extension number in the process - how >do we get a real one allocated? When an extension goes on Standards Track, it can get an extension number. --Paul Hoffman, Director --VPN Consortium From marsh@extendedsubset.com Sun Nov 8 13:28:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7F13A6991 for ; Sun, 8 Nov 2009 13:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 0xARtC-W96eE for ; Sun, 8 Nov 2009 13:28:35 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 2E6A13A6976 for ; Sun, 8 Nov 2009 13:28:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7FJk-000Al2-Do; Sun, 08 Nov 2009 21:29:00 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0F1936673; Sun, 8 Nov 2009 21:28:59 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19TEynlDF24/oUt4fjlGRZvRVeP1LhkoSE= Message-ID: <4AF73817.4080802@extendedsubset.com> Date: Sun, 08 Nov 2009 15:28:55 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Hoffman References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 21:28:36 -0000 Paul Hoffman wrote: > At 5:35 PM +0000 11/8/09, Ben Laurie wrote: >> At some point soon, I guess we'll be releasing an update. It'd be good >> not to consume an experimental extension number in the process - how >> do we get a real one allocated? > > When an extension goes on Standards Track, it can get an extension number. The world is not going to wait in a vulnerable state very long. There is an experimental extension number already sitting in multiple source trees, ready to ship. Ben has asked nicely. If the relevant committees prefer that a different number be used, they'd better speak up soon. - Marsh From ekr@rtfm.com Sun Nov 8 14:23:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EB128C0DE for ; Sun, 8 Nov 2009 14:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 xp79ZzIo25gy for ; Sun, 8 Nov 2009 14:23:19 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 717783A6358 for ; Sun, 8 Nov 2009 14:23:19 -0800 (PST) Received: by ywh13 with SMTP id 13so2716907ywh.29 for ; Sun, 08 Nov 2009 14:23:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.10.9 with SMTP id 9mr605799agj.69.1257719019814; Sun, 08 Nov 2009 14:23:39 -0800 (PST) In-Reply-To: <28425e380911081251j48a1065fv98e782aecf9f7ffc@mail.gmail.com> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <28425e380911081251j48a1065fv98e782aecf9f7ffc@mail.gmail.com> Date: Sun, 8 Nov 2009 14:23:39 -0800 Message-ID: From: Eric Rescorla To: Nagendra Modadugu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 22:23:20 -0000 interesting point, but let me suggest another view: The empty renegotiation extension used on an initial renegotiation says: 1. I support this extension. 2. This is an initial negotiation. Now, it's not important to the server to know that the client supports the extension. Any renegotiation without the extension is automatically suspect. And the client can only use the lack of support to terminate servers if it's willing to break almost all compatibility, in which case TLS only isn't a problem. This leaves us with the second purpose, but that's accomplished just as well by having SSL3/TLS clients offer SSL3 client hello with the TLS version number and then offering the extension on renegotiation only. Does that address your issue? -Ekr On Sun, Nov 8, 2009 at 12:51 PM, Nagendra Modadugu wr= ote: > > SSL3 is still in wide use since it is not considered insecure (other than > the renegotiation issue). =A0Is it feasible to explicitly deprecate SSL3?= =A0Or > state that renegotiation support for SSL3 is deprecated? > > Here is the rationale.=A0 Clients that have both SSL3/TLS1 enabled will s= end a > 'mixed-type' SSL3/TLS1 ClientHello (i.e. Record.version =3D 3.0, > ClientHello.version =3D 3.1). =A0Such clients should, strictly speaking, = not > include TLS extensions, which means that renegotiation should not be allo= wed > by the server regardless of the protocol version negotiated. =A0Consideri= ng > that a majority of clients will continue to support both SSL3 and TLS1 fo= r > some time (as a practical matter), the new extension will not come into > effect unless clients (a) cease sending mixed-type ClientHello messages, = or > (b) send TLS extensions even when Record.version =3D 3.0. > > Option (a) leaves open the possibility for down-grade attacks (i.e. a MIT= M > blocks TLS1 connections, allowing clients to reconnect over SSL3 -- I rec= all > that atleast one major browser will attempt to reconnect over SSL3 if a > TLS1, or mixed-type handshake fails).=A0 Option (b) requires extension su= pport > to be "back-ported" to SSL3. > > I suggest that the draft discourage the use of SSL3 entirely. > > On Thu, Nov 5, 2009 at 10:16 AM, Eric Rescorla wrote: >> I now have a draft extension up at: >> >> >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-reneg= otiate.txt >> >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-reneg= otiate.xml >> >> Comments welcome. >> >> -Ekr >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > From ark@eltex.net Sun Nov 8 13:54:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC77B3A69CB for ; Sun, 8 Nov 2009 13:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC7U6KXSgO6K for ; Sun, 8 Nov 2009 13:54:23 -0800 (PST) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id E43CA3A6991 for ; Sun, 8 Nov 2009 13:54:22 -0800 (PST) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id nA8LsiJB017780; Mon, 9 Nov 2009 00:54:44 +0300 (MSK) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id nA8LsiBh028703; Mon, 9 Nov 2009 00:54:44 +0300 (MSK) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Mon, 9 Nov 2009 00:54:43 +0300 From: ArkanoiD To: oss-security@lists.openwall.com Message-ID: <20091108215443.GA26622@eltex.net> References: <0911051520390.27904@mjc.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sun, 08 Nov 2009 14:24:30 -0800 Cc: tls@ietf.org Subject: Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 22:15:36 -0000 BTW renegotiation handshake looks quite similar to initial handshake from the client point of view; is there a way to detect the attack on client side and drop the connection? From fw@deneb.enyo.de Sun Nov 8 14:26:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C9E3A69DE for ; Sun, 8 Nov 2009 14:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRT8GeYmjT42 for ; Sun, 8 Nov 2009 14:26:52 -0800 (PST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by core3.amsl.com (Postfix) with ESMTP id C13F93A6358 for ; Sun, 8 Nov 2009 14:26:51 -0800 (PST) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1N7GE0-0006oa-VD; Sun, 08 Nov 2009 23:27:09 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1N7GE0-0000iI-Be; Sun, 08 Nov 2009 23:27:08 +0100 From: Florian Weimer To: Paul Hoffman References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> Date: Sun, 08 Nov 2009 23:27:08 +0100 In-Reply-To: (Paul Hoffman's message of "Mon\, 9 Nov 2009 06\:19\:03 +0900") Message-ID: <87y6mg3b5v.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 22:26:52 -0000 * Paul Hoffman: > At 5:35 PM +0000 11/8/09, Ben Laurie wrote: >>At some point soon, I guess we'll be releasing an update. It'd be good >>not to consume an experimental extension number in the process - how >>do we get a real one allocated? > > When an extension goes on Standards Track, it can get an extension > number. The registry requires "IETF consensus". Does this really imply a standards track RFC? From marsh@extendedsubset.com Sun Nov 8 14:31:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784C23A69E3 for ; Sun, 8 Nov 2009 14:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 p2Z2gCCWNXny for ; Sun, 8 Nov 2009 14:31:45 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id BB9B33A6782 for ; Sun, 8 Nov 2009 14:31:45 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7GIt-0008xH-1R; Sun, 08 Nov 2009 22:32:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0041E6673; Sun, 8 Nov 2009 22:32:08 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/vxEN5OdVco4osB9KAthf62ylN59j1CLo= Message-ID: <4AF746E5.7020905@extendedsubset.com> Date: Sun, 08 Nov 2009 16:32:05 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ArkanoiD References: <0911051520390.27904@mjc.redhat.com> <20091108215443.GA26622@eltex.net> In-Reply-To: <20091108215443.GA26622@eltex.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oss-security@lists.openwall.com, tls@ietf.org Subject: Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 22:31:46 -0000 ArkanoiD wrote: > BTW renegotiation handshake looks quite similar to initial handshake from > the client point of view; Yeah, currently it looks identical. > is there a way to detect the attack on client side > and drop the connection? With draft-rescorla-tls-renegotiate, the new header comes back to the client on Server Hello, and this notifies the client that the server believes it's a re-negotation. Even better, it ties it strongly to the previous session, so legit renegotiations are protected, too. - Marsh From housley@vigilsec.com Sun Nov 8 17:50:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976203A6405 for ; Sun, 8 Nov 2009 17:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, 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 kjS2oM6rgCCl for ; Sun, 8 Nov 2009 17:50:20 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 99ED53A635F for ; Sun, 8 Nov 2009 17:50:20 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id EEAE29A477D; Sun, 8 Nov 2009 20:50:41 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ypDiEKQswMYj; Sun, 8 Nov 2009 20:50:45 -0500 (EST) Received: from THINKPADR52.vigilsec.com (host-24-32.meeting.ietf.org [133.93.24.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CE35E9A471B; Sun, 8 Nov 2009 20:50:39 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Nov 2009 20:50:34 -0500 To: Florian Weimer From: Russ Housley In-Reply-To: <87y6mg3b5v.fsf@mid.deneb.enyo.de> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <87y6mg3b5v.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091109015039.CE35E9A471B@odin.smetech.net> Cc: tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-rene got iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:50:21 -0000 > >>At some point soon, I guess we'll be releasing an update. It'd be good > >>not to consume an experimental extension number in the process - how > >>do we get a real one allocated? > > > > When an extension goes on Standards Track, it can get an extension > > number. > >The registry requires "IETF consensus". Does this really imply a >standards track RFC? No. It means there must be an IETF Last Call. Russ From Nicolas.Williams@sun.com Sun Nov 8 18:56:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DA13A6A4E for ; Sun, 8 Nov 2009 18:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 0pJDycbzHJQb for ; Sun, 8 Nov 2009 18:56:13 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 484103A68E5 for ; Sun, 8 Nov 2009 18:56:13 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA92ub9A015556 for ; Mon, 9 Nov 2009 02:56:37 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 nA92uboF026823 for ; Sun, 8 Nov 2009 19:56:37 -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 nA92j6C0011457; Sun, 8 Nov 2009 20:45:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA92j5sM011456; Sun, 8 Nov 2009 20:45:05 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 8 Nov 2009 20:45:05 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091109024504.GT1105@Sun.COM> References: <4AF444EE.9070401@manchester.ac.uk> <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:56:14 -0000 On Fri, Nov 06, 2009 at 06:13:44PM +0100, Martin Rex wrote: > From the original design, and in the two quoted paragraphs above, > it appears that SSL and its successor TLS was intended to be > _very_ transparent, and the spec contains guidance for > security-relevant signaling to the application only for > the initial TLS handshake on a connection (full initial handshake, > and session resume), but _NOT_ for the session renegotiation. > > Therefore, I think, we do have a real shortcoming of the > SSL/TLS protocol, and we really should scramble to fix it. > > That includes improving on the guidance for the signaling > and semantics of a TLS session renegotiate of the TLS > protocol stack to the application -- in a fashion so that > it can be folded back into rfc5246bis. "Signaling" --- sounds like an... API! Nico -- From Nicolas.Williams@sun.com Sun Nov 8 19:02:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BED3A67E2 for ; Sun, 8 Nov 2009 19:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 brdeVh+eBUNk for ; Sun, 8 Nov 2009 19:02:20 -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 87CCD3A689A for ; Sun, 8 Nov 2009 19:02:20 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA932ec1014988 for ; Mon, 9 Nov 2009 03:02:40 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 nA932dPx029028 for ; Sun, 8 Nov 2009 20:02:39 -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 nA92p82P011470; Sun, 8 Nov 2009 20:51:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA92p8TW011469; Sun, 8 Nov 2009 20:51:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 8 Nov 2009 20:51:08 -0600 From: Nicolas Williams To: "Michael D'Errico" Message-ID: <20091109025107.GU1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <82aaz0rf1m.fsf@mid.bfk.de> <4AF5A774.8070002@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF5A774.8070002@pobox.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:02:21 -0000 On Sat, Nov 07, 2009 at 08:59:32AM -0800, Michael D'Errico wrote: > >Therefore, I think a protocol change is less invasive (assuming that > >it is essentially free-for-all-uses IPR-wise). > > Is there any issue with IPR? The proposal is to, effectively, do channel binding. Channel binding goes back a long time, to the early 90s at least (see RFC1508, for an example from 1993). I know of no patents covering the technique. Not that I would -- I don't go looking for patents. But so you know, there's plenty prior art, going back a fair number of years. Nico -- From Nicolas.Williams@sun.com Sun Nov 8 19:13:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3283A67E2 for ; Sun, 8 Nov 2009 19:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 nCZ7GGhYsqEA for ; Sun, 8 Nov 2009 19:13:15 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id DFA1C3A68DB for ; Sun, 8 Nov 2009 19:13:14 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA93DeCO012317 for ; Mon, 9 Nov 2009 03:13:40 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 nA93DePZ033893 for ; Sun, 8 Nov 2009 20:13:40 -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 nA92sc21011477; Sun, 8 Nov 2009 20:54:38 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA92scvd011476; Sun, 8 Nov 2009 20:54:38 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 8 Nov 2009 20:54:38 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091109025438.GV1105@Sun.COM> References: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3C7@LLE2K7-BE01.mitll.ad.local> <4AF621F2.80403@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF621F2.80403@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: "'tls@ietf.org'" Subject: Re: [TLS] To API or not (Re: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:13:16 -0000 On Sat, Nov 07, 2009 at 07:42:10PM -0600, Marsh Ray wrote: > Blumenthal, Uri - 0662 - MITLL wrote: > > IETF can't write precise API because those are application-specific. > > s/can't/shouldn't/ ? RFC2744 (GSS-API v2u1, C-Bindings), for example, specifies a C API, for _applications_; there's also Java bindings. SCTP is another example. The IETF most certainly can, and does, define APIs for _application_ use. > It bugs me the way w3c goes as far as specifying that some APIs must use > UTF-16 host-endian for their string representation, even for things > usually accessed from scripting languages. Interesting. Sounds like a mistake. > > I think that abstract interfaces would be useful for TLS. > > I agree. > > Somebody would have noticed that they were adding a new layer to the > model, and it would have forced an interface change which either would > have been rejected or documented properly. I think so too. Nico -- From ekr@networkresonance.com Sun Nov 8 19:57:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7453228C0E5 for ; Sun, 8 Nov 2009 19:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0QvsHqLrteN for ; Sun, 8 Nov 2009 19:57:07 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9479F28C0E4 for ; Sun, 8 Nov 2009 19:57:07 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 4A72569E39E; Sun, 8 Nov 2009 15:12:34 -0800 (PST) Date: Sun, 08 Nov 2009 15:12:34 -0800 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4AF73817.4080802@extendedsubset.com> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091108231234.4A72569E39E@kilo.networkresonance.com> Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:57:08 -0000 At Sun, 08 Nov 2009 15:28:55 -0600, Marsh Ray wrote: > > Paul Hoffman wrote: > > At 5:35 PM +0000 11/8/09, Ben Laurie wrote: > >> At some point soon, I guess we'll be releasing an update. It'd be good > >> not to consume an experimental extension number in the process - how > >> do we get a real one allocated? > > > > When an extension goes on Standards Track, it can get an extension number. > > The world is not going to wait in a vulnerable state very long. There is > an experimental extension number already sitting in multiple source > trees, ready to ship. Ben has asked nicely. > > If the relevant committees prefer that a different number be used, > they'd better speak up soon. I'm a bit biased because I'm the author of this draft, but I really don't see a problem with getting a reservation for a number out of a 16 bit space nowish. Joe? Pasi/Tim? -Ekr From paul.hoffman@vpnc.org Sun Nov 8 20:28:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77ED428C143 for ; Sun, 8 Nov 2009 20:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[AWL=0.149, 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 CJUyCcW0DR5Q for ; Sun, 8 Nov 2009 20:28:28 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AD7D828C144 for ; Sun, 8 Nov 2009 20:28:28 -0800 (PST) Received: from [133.93.128.35] (host-16-63.meeting.ietf.org [133.93.16.63]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nA94Sm4V024234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2009 21:28:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091109015039.CE35E9A471B@odin.smetech.net> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <87y6mg3b5v.fsf@mid.deneb.enyo.de> <20091109015039.CE35E9A471B@odin.smetech.net> Date: Mon, 9 Nov 2009 13:28:45 +0900 To: Russ Housley , Florian Weimer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-rene got iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:28:29 -0000 At 8:50 PM -0500 11/8/09, Russ Housley wrote: >> >>At some point soon, I guess we'll be releasing an update. It'd be good >>>>not to consume an experimental extension number in the process - how >>>>do we get a real one allocated? >>> >>> When an extension goes on Standards Track, it can get an extension >>> number. >> >>The registry requires "IETF consensus". Does this really imply a >>standards track RFC? > >No. It means there must be an IETF Last Call. Sorry, Russ is correct. --Paul Hoffman, Director --VPN Consortium From fweimer@bfk.de Sun Nov 8 23:41:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1623A6AF7 for ; Sun, 8 Nov 2009 23:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkBQeULS6JDR for ; Sun, 8 Nov 2009 23:41:34 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id DB6493A6A1B for ; Sun, 8 Nov 2009 23:41:32 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1N7Osk-00082w-9g; Mon, 09 Nov 2009 08:41:46 +0100 Received: by bfk.de with local id 1N7Osk-0002ff-4P; Mon, 09 Nov 2009 07:41:46 +0000 To: Dean Anderson References: From: Florian Weimer Date: Mon, 09 Nov 2009 07:41:46 +0000 In-Reply-To: (Dean Anderson's message of "Fri\, 6 Nov 2009 17\:29\:23 -0500 \(EST\)") Message-ID: <82639kta9x.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eric Rescorla , "tls@ietf.org" Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:41:34 -0000 * Dean Anderson: >> Theoretically, this attack can be detected by the server, > > Theoretically, I think not. I was referring to the sketched attack in the previous paragraph. In our case, the server could notice the changed client certificate in the renegotiation and bail out, or disable renegotiation altogether. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Yair.Elharrar@audiocodes.com Mon Nov 9 04:16:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEBEF3A6A19 for ; Mon, 9 Nov 2009 04:16:21 -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 w9O5hELeJnN1 for ; Mon, 9 Nov 2009 04:16:21 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id D1A0A3A68B7 for ; Mon, 9 Nov 2009 04:16:19 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.1.65]) by incoming.audiocodes.com with ESMTP; 09 Nov 2009 13:53:32 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80::d9:1fca:eaba:8828]) by aclcas02.corp.audiocodes.com ([::1]) with mapi; Mon, 9 Nov 2009 14:17:16 +0200 From: Yair Elharrar To: "tls@ietf.org" Date: Mon, 9 Nov 2009 14:17:24 +0200 Thread-Topic: draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: AcphNpiYsAWri5X4SDqhcfiTfcxkGA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AGyK A2or BifF Bvtc B7zP CQY0 DLGW D0/K D+6+ ET8e E4Vl Fktc GqCQ I3NY JmS6 J1uR; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4125738D-DB00-470A-A62A-07A3191F20F0}; eQBhAGkAcgAuAGUAbABoAGEAcgByAGEAcgBAAGEAdQBkAGkAbwBjAG8AZABlAHMALgBjAG8AbQA=; Mon, 09 Nov 2009 12:17:24 GMT; ZAByAGEAZgB0AC0AcgBlAHMAYwBvAHIAbABhAC0AdABsAHMALQByAGUAbgBlAGcAbwB0AGkAYQB0AGUAIABhAG4AZAAgAE0ASQBUAE0AIAByAGUAcwBpAHMAdABhAG4AYwBlAA== x-cr-puzzleid: {4125738D-DB00-470A-A62A-07A3191F20F0} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:17:30 -0000 The proposed draft is intended to resolve an MITM attack scenario, but is t= he new extension tamper-resistant? Since the MITM handles all traffic between the real client and real server,= it could add a fake extension to the 2nd ClientHello with its original ver= ify_data, and empty the returned extension in the ServerHello. In addition, until such time that all clients in the world start supporting= this extension (e.g. kiosks in airports), servers will have to support bac= kward compatibility. The MITM can downgrade every client by simply removing= the extension from the ClientHello. Yair This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message From ynir@checkpoint.com Mon Nov 9 04:36:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069E53A6805 for ; Mon, 9 Nov 2009 04:36:27 -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 H-6oGisQhqNJ for ; Mon, 9 Nov 2009 04:36:26 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B6DC93A672F for ; Mon, 9 Nov 2009 04:36:25 -0800 (PST) X-CheckPoint: {4AF809D4-6-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7D76029C00B; Mon, 9 Nov 2009 14:36:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5919029C002; Mon, 9 Nov 2009 14:36:50 +0200 (IST) X-CheckPoint: {4AF809D4-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA9Canc6015583; Mon, 9 Nov 2009 14:36:49 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Nov 2009 14:36:53 +0200 From: Yoav Nir To: Yair Elharrar Date: Mon, 9 Nov 2009 14:36:47 +0200 Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: AcphOVCIx8Rz2UcRREmZUnBnx/9AKg== Message-ID: <195C3B4A-77FC-41AD-A0B7-6A3E076BE190@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-33-290133861"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:36:27 -0000 --Apple-Mail-33-290133861 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Below On Nov 9, 2009, at 2:17 PM, Yair Elharrar wrote: > The proposed draft is intended to resolve an MITM attack scenario, > but is the new extension tamper-resistant? It's as resistant as TLS is. > Since the MITM handles all traffic between the real client and real > server, it could add a fake extension to the 2nd ClientHello with > its original verify_data, and empty the returned extension in the > ServerHello. The Finished messaged at the end of the TLS handshake signs all the previous data. Unless the MITM can replicate the server's calculation of the opaque_verify_data field, the client will notice that the finished message is wrong (it signs an extension that the client did not send). To calculate the opaque_verify_data field, the MITM would need the (pre_)master_secret, and that is encrypted using the server's public key. So no, the MITM cannot mess with the extensions. > > In addition, until such time that all clients in the world start > supporting this extension (e.g. kiosks in airports), servers will > have to support backward compatibility. The MITM can downgrade every > client by simply removing the extension from the ClientHello. They can't downgrade the client, but the client can't expect any server to support the extension. Maybe the browser vendors can disable the green EV indication for servers that don't support the extension. > Yair --Apple-Mail-33-290133861 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTEwOTEy MzY0OFowIwYJKoZIhvcNAQkEMRYEFPq7gn3iIHYlLXVjcDi3o0TPJE8eMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQBi2TUbSUQw c4At+qkhMLWzR1DUDzjGMpi6Nkp1cd8hLMYQnogjUTFligfU0eron23xdUrzZmyh3KD+0emfC8JK nBTcmUHuJSdc7mcaTEDRnm/ywAYcI0bsVPuzhLUDErn13yQjOaeKwK7y6dBK3snXMi9Y6SuWH4b7 C6dYv9uVkSmmXrTkIJdGobAJJ0bS9MGyXpUvcsNDMDI7+xc5S6cqcv/CEUbteo15cr6xOi2IC1Ag CMwwkqqiYWr5lOM6AIevo+i8qRGeAwVg5Kav4GPW04+hwSCJ1xsO57xd7KthW9/xyweXCuZM6B8U +yY6g0zTWdjcQRFvGMT1oxbXkLZEAAAAAAAA --Apple-Mail-33-290133861-- From ynir@checkpoint.com Mon Nov 9 04:59:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421613A6AF6 for ; Mon, 9 Nov 2009 04:59:05 -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 acsNOnzCW4MK for ; Mon, 9 Nov 2009 04:59:04 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EFD5C3A6A0D for ; Mon, 9 Nov 2009 04:59:03 -0800 (PST) X-CheckPoint: {4AF80F23-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B5F9229C00B; Mon, 9 Nov 2009 14:59:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9408C29C007 for ; Mon, 9 Nov 2009 14:59:29 +0200 (IST) X-CheckPoint: {4AF80F23-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA9CxSc6021871 for ; Mon, 9 Nov 2009 14:59:29 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Nov 2009 14:59:32 +0200 From: Yoav Nir To: "tls@ietf.org list" Date: Mon, 9 Nov 2009 14:59:27 +0200 Thread-Topic: Could the renegotiation attack be used for session hijacking? Thread-Index: AcphPHrrNqDIrBl6R52p3VeQwkc5tw== Message-ID: <34C84617-2B75-4F6D-9F0B-50A528D445C8@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-36-291493463"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Subject: [TLS] Could the renegotiation attack be used for session hijacking? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:59:05 -0000 --Apple-Mail-36-291493463 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi. One of our security experts came up with an extension to the renegotiation attack, that may lead to session hijacking. It's probably not relevant for HTTPS, because those connections are short- lived, but may be relevant for applications with longer-lived sessions that require rekeying. draft-rescorla-tls-renegotiation should solve this as well: 1. Client connects without a certificate, but the session is authenticated by the protocol (like an HTTP form or FTP login). The MITM just proxies the connection to allow the client to authenticate. 2. After a while, the session requires rekeying, so the server sends a HelloRequest. 3. The MITM stops passing data to the client, and sends a ClientHello to the server. 4. The server and MITM complete the handshake, and the MITM has effectively hijacked the session from the client. The persistent application session means that the MITM is now authenticated to the server as the client. Seems to me that this will work, right? Am I missing something? Yoav --Apple-Mail-36-291493463 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTEwOTEy NTkyOFowIwYJKoZIhvcNAQkEMRYEFEsR4zPnMZVYmIpN708CvgmgdfY8MIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQBfnhICEj15 FsExFkaJLQx9JwRjPt+aIAx9TRZtm/HDAGUaF1VfjIpHpauDa8HbwYNjHwAMHQqh8amuKVwzaaZJ 9xp3n6xV0aHo5xvXzEEkliilnfKDQcb63qQaigQ4YzObRGWy9G+cBRf5qsTzDOPBoORxb/QexIvu Lorgpli7lNbzAVOXNHW8yAyV+r7GYEZuJUxrzabSeOttN+tDhR30ROcbeXikfVwTZlHjmz28EOmX +LDjJhX/0epRWbdcR9oCFbf1WW91lTFerQvkJFU3GW5pZdQ3BrZPw5TFUXL7l5sO4a2y4cIh6MtR JusIus2l10EYIkM67tyRJbrgpM/pAAAAAAAA --Apple-Mail-36-291493463-- From marsh@extendedsubset.com Mon Nov 9 05:45:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF913A6AD7 for ; Mon, 9 Nov 2009 05:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 bfnHK4lWiXqi for ; Mon, 9 Nov 2009 05:45:14 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 9D8DE3A6AD4 for ; Mon, 9 Nov 2009 05:45:14 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7UYu-000IUR-Ei; Mon, 09 Nov 2009 13:45:40 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 27DFE6673; Mon, 9 Nov 2009 13:45:39 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18EF5vytyuDZW51hzGiQPYLy/GvGrMvxUk= Message-ID: <4AF81CFF.8010803@extendedsubset.com> Date: Mon, 09 Nov 2009 07:45:35 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yair Elharrar References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:45:15 -0000 Yair Elharrar wrote: > The proposed draft is intended to resolve an MITM attack scenario, > but is the new extension tamper-resistant? > > Since the MITM handles all traffic between the real client and real > server, it could add a fake extension to the 2nd ClientHello with its > original verify_data, and empty the returned extension in the > ServerHello. A valid concern, which I believe is addressed by the fact that the 'Finished' message in TLS contains a MAC which covers extensions present on the Client and Server Hellos. IIRC, earlier SSLs did not cover extensions with a MAC. > In addition, until such time that all clients in the world start > supporting this extension (e.g. kiosks in airports), servers will > have to support backward compatibility. It will be a trade-off for each server admin to weigh and decide their policy. I suspect many admins will prefer not to allow insecure connections from unpatched airport kiosks. > The MITM can downgrade every > client by simply removing the extension from the ClientHello. I think that is not the case with modern versions of TLS. > Yair > > > This email and any files transmitted with it are confidential > material. They are intended solely for the use of the designated > individual or entity to whom they are addressed. If the reader of > this message is not the intended recipient, you are hereby notified > that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. Eeek! > If you have received this email in error please immediately notify > the sender and delete or destroy any copy of this message - Marsh From ynir@checkpoint.com Mon Nov 9 05:53:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B26C3A6AE5 for ; Mon, 9 Nov 2009 05:53:00 -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 aueFDR+nt2dM for ; Mon, 9 Nov 2009 05:52:59 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0142E3A6A78 for ; Mon, 9 Nov 2009 05:52:58 -0800 (PST) X-CheckPoint: {4AF81BC5-6-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EDAC229C008; Mon, 9 Nov 2009 15:53:23 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id CCC8E29C007; Mon, 9 Nov 2009 15:53:23 +0200 (IST) X-CheckPoint: {4AF81BC5-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA9DrNc6007395; Mon, 9 Nov 2009 15:53:23 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Nov 2009 15:53:26 +0200 From: Yoav Nir To: Marsh Ray Date: Mon, 9 Nov 2009 15:53:21 +0200 Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: AcphRAKJsW4FhNJwTuKJvS/5iM4a1Q== Message-ID: References: <4AF81CFF.8010803@extendedsubset.com> In-Reply-To: <4AF81CFF.8010803@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-38-294727374"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "tls@ietf.org list" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:53:00 -0000 --Apple-Mail-38-294727374 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Nov 9, 2009, at 3:45 PM, Marsh Ray wrote: > Yair Elharrar wrote: >> The proposed draft is intended to resolve an MITM attack scenario, >> but is the new extension tamper-resistant? >> >> Since the MITM handles all traffic between the real client and real >> server, it could add a fake extension to the 2nd ClientHello with its >> original verify_data, and empty the returned extension in the >> ServerHello. > > A valid concern, which I believe is addressed by the fact that the > 'Finished' message in TLS contains a MAC which covers extensions > present > on the Client and Server Hellos. > > IIRC, earlier SSLs did not cover extensions with a MAC. I think SSLv3 did not allow for client extensions at all, and TLSv1.0 already covered everything. > >> In addition, until such time that all clients in the world start >> supporting this extension (e.g. kiosks in airports), servers will >> have to support backward compatibility. > > It will be a trade-off for each server admin to weigh and decide their > policy. I suspect many admins will prefer not to allow insecure > connections from unpatched airport kiosks. I suspect you have a way too optimistic view of administrators. Currently exactly 0% of browsers are patched. It will be years before even 50% or browsers are patched. Yoav --Apple-Mail-38-294727374 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTEwOTEz NTMyMVowIwYJKoZIhvcNAQkEMRYEFLePRu66ryV9APuCNj05M+wIPm5JMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQBAJRB9IUly ezat0dxFA1AV8BIAQCmJDiW5T9tecej85S/pKujUp+ZH212iVV3WGaEeDE32k0s3wBhP45PnMhkH le7ntAgyO+4ERgCl557z4wlWkEugeq4geJV6QGsm+WCqn9lSI9fhdWUy8BhBCoO5JRmRTu/JET8p wTDygANEmZX4Y/aSsGxzufc1tZPHQ6l6qb1VgTCjd9OsF607vE2TJJ7SMWaugIJMayrEP5hCgKRK EXtfpPkif+Wfh+eY2ASE7ktfOgaDUNHBqf3IEbGoWhUPP2eHOy3EOnFfHOr3rzXnwfEn5G9O3/GO 19I3d/P6zZBCf5aytSh4yXlkr1aWAAAAAAAA --Apple-Mail-38-294727374-- From lists@drh-consultancy.demon.co.uk Mon Nov 9 06:01:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286D43A6B6E for ; Mon, 9 Nov 2009 06:01:03 -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 bvQbpUL2CtGh for ; Mon, 9 Nov 2009 06:01:02 -0800 (PST) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by core3.amsl.com (Postfix) with ESMTP id E4BEC3A6B6C for ; Mon, 9 Nov 2009 06:01:01 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49754 helo=[192.168.7.8]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10587) with esmtpa (authdaemon_plain:drh) id 1N7Uo7-000879-Fu (Exim 4.69) (return-path ); Mon, 09 Nov 2009 14:01:24 +0000 Message-ID: <4AF820B4.6070303@drh-consultancy.demon.co.uk> Date: Mon, 09 Nov 2009 14:01:24 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yoav Nir References: <4AF81CFF.8010803@extendedsubset.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org list" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:01:03 -0000 Yoav Nir wrote: > > On Nov 9, 2009, at 3:45 PM, Marsh Ray wrote: > >> Yair Elharrar wrote: >>> The proposed draft is intended to resolve an MITM attack scenario, >>> but is the new extension tamper-resistant? >>> >>> Since the MITM handles all traffic between the real client and real >>> server, it could add a fake extension to the 2nd ClientHello with its >>> original verify_data, and empty the returned extension in the >>> ServerHello. >> >> A valid concern, which I believe is addressed by the fact that the >> 'Finished' message in TLS contains a MAC which covers extensions present >> on the Client and Server Hellos. >> >> IIRC, earlier SSLs did not cover extensions with a MAC. > > I think SSLv3 did not allow for client extensions at all, and TLSv1.0 > already covered everything. > I think that SSLv3 did allow additional arbitrary data to be added after a ClientHello without specifying the format (meaning that technically extensions could be included) and that this additional data was included in MACs. However testing has shown that many implementations (including one ancient version of OpenSSL) didn't handle this properly meaning that including extensions in SSLv3 can result in handshake failure. OpenSSL did include extensions in SSLv3 but the resulting failures have meant we don't do this any more. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From Yair.Elharrar@audiocodes.com Mon Nov 9 06:43:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2733A6A05 for ; Mon, 9 Nov 2009 06:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 Bn4OdOLb6-7o for ; Mon, 9 Nov 2009 06:43:13 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id 82E523A6774 for ; Mon, 9 Nov 2009 06:43:11 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.0.13]) by incoming.audiocodes.com with ESMTP; 09 Nov 2009 16:20:24 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80:0000:0000:0000:00d9:1fca:234.186.136.40]) by aclcas.corp.audiocodes.com ([10.1.0.13]) with mapi; Mon, 9 Nov 2009 16:44:08 +0200 From: Yair Elharrar To: Yoav Nir Date: Mon, 9 Nov 2009 16:44:11 +0200 Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: AcphOVCIx8Rz2UcRREmZUnBnx/9AKgAEXhbg Message-ID: References: <195C3B4A-77FC-41AD-A0B7-6A3E076BE190@checkpoint.com> In-Reply-To: <195C3B4A-77FC-41AD-A0B7-6A3E076BE190@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:43:13 -0000 >> 3. The MITM stops passing data to the client, and sends a ClientHello to= the server. This ClientHello should be encrypted with the initial session's keys. -- This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message From ynir@checkpoint.com Mon Nov 9 07:01:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B86A28C13E for ; Mon, 9 Nov 2009 07:01:20 -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 wSHZDM0bM0zP for ; Mon, 9 Nov 2009 07:01:19 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3AF9628C12A for ; Mon, 9 Nov 2009 07:01:19 -0800 (PST) X-CheckPoint: {4AF82BC9-6-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3FFE229C009; Mon, 9 Nov 2009 17:01:44 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 14D8929C007; Mon, 9 Nov 2009 17:01:44 +0200 (IST) X-CheckPoint: {4AF82BC9-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA9F1hc6027588; Mon, 9 Nov 2009 17:01:43 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Nov 2009 17:01:47 +0200 From: Yoav Nir To: Yair Elharrar Date: Mon, 9 Nov 2009 17:01:41 +0200 Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: AcphTY4acpTcwpKuQQO+EDXtuSAIrw== Message-ID: <513EC5BE-3BBB-487F-A2CD-6A3504E26E5A@checkpoint.com> References: <195C3B4A-77FC-41AD-A0B7-6A3E076BE190@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-39-298827162"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:01:20 -0000 --Apple-Mail-39-298827162 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Oh. OK. Thanks. On Nov 9, 2009, at 4:44 PM, Yair Elharrar wrote: >>> 3. The MITM stops passing data to the client, and sends a >>> ClientHello to the server. > > This ClientHello should be encrypted with the initial session's keys. > --Apple-Mail-39-298827162 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTEwOTE1 MDE0MVowIwYJKoZIhvcNAQkEMRYEFHvNZqhj2Uqgr6PRg3c8tWmUTBNvMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQATSZgJ8+hm Zmu3X7kwe3fyvilxR2XKBy3WMU3lGgjlkSEIe02Z5ph3fJADbu4CM/3zICVp9Gtfa7gBPMqVs3pr BferL2pwxWnSp7kJgssqr7xlrBMY1xNPbnG1OYbPHh8IMitoIeoH2WAGnp3/4hVQnwI+DL2M7Pdp sPHFl2uQ+XzAeajakL0N8boubq3+UT/JDC4xFlfNEFPg/EyFPHlBubeaRKEF2HXYs1hGlmDwKvCi mGHLHSg9qHOjJw9vxYviR85la1kC41YoMcB0ghACEWr6mJDJnsgDKSCrUttMt6xjv+oPG8tNLkRz R2axjXm0KpUHI0dQBiQ44w71EESMAAAAAAAA --Apple-Mail-39-298827162-- From marsh@extendedsubset.com Mon Nov 9 07:17:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577813A6B87 for ; Mon, 9 Nov 2009 07:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 csL+OQBdFv8r for ; Mon, 9 Nov 2009 07:17:50 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id C01B53A6B81 for ; Mon, 9 Nov 2009 07:17:49 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7W0U-000J7d-LJ; Mon, 09 Nov 2009 15:18:14 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DD8D56678; Mon, 9 Nov 2009 15:18:12 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19R9cHW1XwLubU5lAsSPDOxmnD8qw/J6xw= Message-ID: <4AF832B1.30309@extendedsubset.com> Date: Mon, 09 Nov 2009 09:18:09 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yoav Nir , "tls@ietf.org list" References: <34C84617-2B75-4F6D-9F0B-50A528D445C8@checkpoint.com> In-Reply-To: <34C84617-2B75-4F6D-9F0B-50A528D445C8@checkpoint.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Could the renegotiation attack be used for session hijacking? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:17:51 -0000 Yoav Nir wrote: > > 1. Client connects without a certificate, but the session is > authenticated by the protocol (like an HTTP form or FTP login). The MITM > just proxies the connection to allow the client to authenticate. TLS is now doing its job providing encryption and MITM cannot read or modify traffic. > 2. After a while, the session requires rekeying, so the server sends a > HelloRequest. This will be observable by MITM because the record layer does not encrypt the payload type identifier. It will be seen as a handshake message from server to client, I believe of predictable size. > 3. The MITM stops passing data to the client, and sends a ClientHello to > the server. The renegotiation handshaking is covered by the encryption state of the previous session. So this attack is defeated. It may be that some TLS servers would accept an unencrypted Client Hello at this point, or even an SSLv2-compatible Client Hello which may be handled by a different code path. But I don't think those would be bugs in the TLS protocol, just implementation bugs. - Marsh From lists@drh-consultancy.demon.co.uk Mon Nov 9 08:13:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4B73A6957 for ; Mon, 9 Nov 2009 08:13:21 -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 Jej0GZeySAuw for ; Mon, 9 Nov 2009 08:13:19 -0800 (PST) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by core3.amsl.com (Postfix) with ESMTP id 7C70F3A684A for ; Mon, 9 Nov 2009 08:13:19 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50995 helo=[192.168.7.8]) by relay05.mail.eu.clara.net (relay.clara.net [213.253.3.45]:10587) with esmtpa (authdaemon_plain:drh) id 1N7WsC-00031t-HP (Exim 4.69) for tls@ietf.org (return-path ); Mon, 09 Nov 2009 16:13:44 +0000 Message-ID: <4AF83FB9.9060302@drh-consultancy.demon.co.uk> Date: Mon, 09 Nov 2009 16:13:45 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> In-Reply-To: <20091108231234.4A72569E39E@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:13:21 -0000 Eric Rescorla wrote: > At Sun, 08 Nov 2009 15:28:55 -0600, > Marsh Ray wrote: >> Paul Hoffman wrote: >>> At 5:35 PM +0000 11/8/09, Ben Laurie wrote: >>>> At some point soon, I guess we'll be releasing an update. It'd be good >>>> not to consume an experimental extension number in the process - how >>>> do we get a real one allocated? >>> When an extension goes on Standards Track, it can get an extension number. >> The world is not going to wait in a vulnerable state very long. There is >> an experimental extension number already sitting in multiple source >> trees, ready to ship. Ben has asked nicely. >> >> If the relevant committees prefer that a different number be used, >> they'd better speak up soon. > > I'm a bit biased because I'm the author of this draft, but > I really don't see a problem with getting a reservation for > a number out of a 16 bit space nowish. Joe? Pasi/Tim? > Can this not be handled as a special case since the circumstances are clearly exceptional? For example saying in advance what number it will get when everything is done officially? Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Mon Nov 9 08:46:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C003A6B80 for ; Mon, 9 Nov 2009 08:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.115, 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 PJlvHXTclwjI for ; Mon, 9 Nov 2009 08:46:11 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 105C63A6A29 for ; Mon, 9 Nov 2009 08:46:10 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA9GkWmF002758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 17:46:32 +0100 (MET) From: Martin Rex Message-Id: <200911091646.nA9GkW6n008821@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Mon, 9 Nov 2009 17:46:32 +0100 (MET) In-Reply-To: from "Yoav Nir" at Nov 9, 9 03:53:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:46:12 -0000 Yoav Nir wrote: > > On Nov 9, 2009, at 3:45 PM, Marsh Ray wrote: > > > Yair Elharrar wrote: > >> The proposed draft is intended to resolve an MITM attack scenario, > >> but is the new extension tamper-resistant? It is tamper resistent in the same fashion as the rest of SSL/TLS. No more, but also no less! > > > IIRC, earlier SSLs did not cover extensions with a MAC. Those that have this problem are not interoperable with a TLS+extensions handshake (which might be why some browsers added a handshake retry mechanism for a naked SSLv3 ClientHello. > > I think SSLv3 did not allow for client extensions at all, and TLSv1.0 > already covered everything. The problem with SSLv3 is, that the spec was finalized after the implementations had been shipped. :-| If I refer to SSLv3, I always base my assuption on the SSLv3 internet draft document from Nov 18, 1996 document, which was the starting point for TLS v1.0. It contains the following note at the top of page 24 (5.6.1.2. ClientHello): Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. Which means in principle that SSLv3 allows extensions to be used, and the extra data will be integrity protected by the finished messages of the handshake. If you look at the TLSv1.0 spec (rfc2246) and TLSv1.1 spec (rfc4346), neither contains extension data in the ServerHello in the base spec. Is there a reason why TLS extensions should _NOT_ be applicable to SSLv3 in just the same way they're applicable to TLSv1.0 and TLSv1.1 ? There may be SSLv3 servers out there that choke on extension data in the ClientHello. But that doesn't mean that one could not upgrade SSLv3 servers to support TLS extensions. The more interesting question is IMHO -- which TLS clients will choke when an SSLv3 server returns a ServerHello extension? spec-wise, a ServerHello extension is as unusual to SSLv3 as it is to TLSv1.0. -Martin From mrex@sap.com Mon Nov 9 09:19:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850773A6816 for ; Mon, 9 Nov 2009 09:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 DLyiJNbJvqzj for ; Mon, 9 Nov 2009 09:19:48 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 7FEF13A676A for ; Mon, 9 Nov 2009 09:19:48 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA9HKBgm015550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 18:20:11 +0100 (MET) From: Martin Rex Message-Id: <200911091720.nA9HKBC1010730@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Mon, 9 Nov 2009 18:20:11 +0100 (MET) In-Reply-To: <200911091646.nA9GkW6n008821@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 9, 9 05:46:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:19:49 -0000 Hmmm, I think I can answer this myself: Martin Rex wrote: > > If you look at the TLSv1.0 spec (rfc2246) and TLSv1.1 spec (rfc4346), > neither contains extension data in the ServerHello in the base spec. > > Is there a reason why TLS extensions should _NOT_ be applicable > to SSLv3 in just the same way they're applicable to TLSv1.0 and TLSv1.1 ? > > > There may be SSLv3 servers out there that choke on extension data > in the ClientHello. But that doesn't mean that one could not > upgrade SSLv3 servers to support TLS extensions. The more interesting > question is IMHO -- which TLS clients will choke when an SSLv3 server > returns a ServerHello extension? spec-wise, a ServerHello extension > is as unusual to SSLv3 as it is to TLSv1.0. Since such an SSLv3 server will only be returning extensions in an extended ServerHello that the TLS client asserted, and in our specific situation here, the new extension for secure renegotiation that we're just defining, then the answer is: Test the update before shipping it, and all TLS clients with the secure renegotiation update ought to interoperate smoothly with SSLv3 servers that implement this TLS extension. Adding support for other/existing TLS extensions might eventually confuse or upset installed base TLS clients, so I wouldn't try those this time. :) -Martin From ekr@networkresonance.com Mon Nov 9 09:58:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0F43A6948 for ; Mon, 9 Nov 2009 09:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.04 X-Spam-Level: X-Spam-Status: No, score=0.04 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c6pbR4XUXBa for ; Mon, 9 Nov 2009 09:58:48 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 0B3443A6945 for ; Mon, 9 Nov 2009 09:58:48 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 8DF8F69E5CB; Mon, 9 Nov 2009 09:59:54 -0800 (PST) Date: Mon, 09 Nov 2009 09:59:53 -0800 From: Eric Rescorla To: Dr Stephen Henson In-Reply-To: <4AF83FB9.9060302@drh-consultancy.demon.co.uk> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> <4AF83FB9.9060302@drh-consultancy.demon.co.uk> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091109175954.8DF8F69E5CB@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:58:49 -0000 At Mon, 09 Nov 2009 16:13:45 +0000, Dr Stephen Henson wrote: > > Eric Rescorla wrote: > > At Sun, 08 Nov 2009 15:28:55 -0600, > > Marsh Ray wrote: > >> Paul Hoffman wrote: > >>> At 5:35 PM +0000 11/8/09, Ben Laurie wrote: > >>>> At some point soon, I guess we'll be releasing an update. It'd be good > >>>> not to consume an experimental extension number in the process - how > >>>> do we get a real one allocated? > >>> When an extension goes on Standards Track, it can get an extension number. > >> The world is not going to wait in a vulnerable state very long. There is > >> an experimental extension number already sitting in multiple source > >> trees, ready to ship. Ben has asked nicely. > >> > >> If the relevant committees prefer that a different number be used, > >> they'd better speak up soon. > > > > I'm a bit biased because I'm the author of this draft, but > > I really don't see a problem with getting a reservation for > > a number out of a 16 bit space nowish. Joe? Pasi/Tim? > > > > Can this not be handled as a special case since the circumstances are clearly > exceptional? For example saying in advance what number it will get when > everything is done officially? I don't think the problem here is really the code point assignment. I would imagine the IESG and IANA to be pretty good about doing advance assignments once the WG has converged on the exact contents of the extension. I know we had pretty good consensus within a smaller group, but if when we run it by some cryptographers they say it's insecure we'll need to change it, at which point it won't really help to have deployed code with the "early" code point. -Ekr From Nicolas.Williams@sun.com Mon Nov 9 10:14:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640613A6858 for ; Mon, 9 Nov 2009 10:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 WMPxeDmIgQ+Q for ; Mon, 9 Nov 2009 10:14:10 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 7F1FB3A6814 for ; Mon, 9 Nov 2009 10:14:10 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA9IEbmc018718 for ; Mon, 9 Nov 2009 18:14:37 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 nA9IEagg031746 for ; Mon, 9 Nov 2009 11:14:36 -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 nA9HtZMN011737; Mon, 9 Nov 2009 11:55:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9HtZtB011736; Mon, 9 Nov 2009 11:55:35 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 9 Nov 2009 11:55:35 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091109175534.GB1105@Sun.COM> References: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> <4AF497C5.5060801@REDHAT.COM> <4AF4A091.3070609@pobox.com> <4AF4B423.2000309@extendedsubset.com> <20091106234757.GN1105@Sun.COM> <4AF50CFD.7070705@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF50CFD.7070705@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] Simple way to drop re-negotiation in HTTP (Re: draft-rescorla-tls-renegotiate.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:14:11 -0000 On Sat, Nov 07, 2009 at 12:00:29AM -0600, Marsh Ray wrote: > Nicolas Williams wrote: > > The simplest way to drop re-negotiation in web servers is this (based on > > an idea by Nelson Bolyard): > > Wow that does make it sound easy. All we need to do for HTTPS is get a > new port number assigned and the entire burden of the solution passes > from the TLS specs to server implementors and site admins? [Complaints that new port numbers for this are not really feasible elided.] For services inside a firewall this would be simple enough. For all others one may split the public vs. for-authenticated-users services across multiple IP addresses rather than port numbers; this is [much?] harder to automate. But you convince me that this is not realistic. To properly automate this would require... software updates, which is pretty much what we need to fix the bug in the first place; if this workaround is not automated, then it won't be deployed. Must likely, as you say, the world will sit in the vulnerable state for a long time. Very unfortunate, that. Nico -- From Nicolas.Williams@sun.com Mon Nov 9 10:36:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87523A6359 for ; Mon, 9 Nov 2009 10:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 s8L1de4g3Hj8 for ; Mon, 9 Nov 2009 10:36:47 -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 DC0423A659C for ; Mon, 9 Nov 2009 10:36:41 -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 nA9Ib3l3020085 for ; Mon, 9 Nov 2009 18:37:03 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 nA9Ib3Ht054507 for ; Mon, 9 Nov 2009 11:37:03 -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 nA9II15N011755; Mon, 9 Nov 2009 12:18:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9II1bk011754; Mon, 9 Nov 2009 12:18:01 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 9 Nov 2009 12:18:01 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091109181800.GD1105@Sun.COM> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091108231234.4A72569E39E@kilo.networkresonance.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org, Paul Hoffman Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:36:48 -0000 On Sun, Nov 08, 2009 at 03:12:34PM -0800, Eric Rescorla wrote: > At Sun, 08 Nov 2009 15:28:55 -0600, > Marsh Ray wrote: > > > > Paul Hoffman wrote: > > > At 5:35 PM +0000 11/8/09, Ben Laurie wrote: > > >> At some point soon, I guess we'll be releasing an update. It'd be good > > >> not to consume an experimental extension number in the process - how > > >> do we get a real one allocated? > > > > > > When an extension goes on Standards Track, it can get an extension number. > > > > The world is not going to wait in a vulnerable state very long. There is > > an experimental extension number already sitting in multiple source > > trees, ready to ship. Ben has asked nicely. > > > > If the relevant committees prefer that a different number be used, > > they'd better speak up soon. > > I'm a bit biased because I'm the author of this draft, but > I really don't see a problem with getting a reservation for > a number out of a 16 bit space nowish. Joe? Pasi/Tim? I think we need emergency allocation procedures. If, for the sake of argument, your I-D should fail to become a Proposed Standard, then any allocations made for it would become historical. I think now would be a fine time to make an emergency allocation and set the precedent. A subsequent document outlining emergency allocation procedures for the IETF and IANA would be a good thing to have. Not only do we need emergency allocations, but also confidentiality until the time is right for public disclosure. This last is bound to be somewhat controversial, I'm sure. But then, I think too that implementors can probably manage to fix allocations reasonably late in the process IF the process of fixing a protocol vulnerability is not too long. Nico -- From Nicolas.Williams@sun.com Mon Nov 9 10:47:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5203A69A7 for ; Mon, 9 Nov 2009 10:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 PhaKw105ZMEW for ; Mon, 9 Nov 2009 10:47:28 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id E09283A692E for ; Mon, 9 Nov 2009 10:47:27 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA9IlsLJ006240 for ; Mon, 9 Nov 2009 18:47:54 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 nA9IlsaD062031 for ; Mon, 9 Nov 2009 11:47:54 -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 nA9ILMVS011761; Mon, 9 Nov 2009 12:21:22 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9ILLP3011760; Mon, 9 Nov 2009 12:21:21 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 9 Nov 2009 12:21:21 -0600 From: Nicolas Williams To: Yoav Nir Message-ID: <20091109182120.GE1105@Sun.COM> References: <195C3B4A-77FC-41AD-A0B7-6A3E076BE190@checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <195C3B4A-77FC-41AD-A0B7-6A3E076BE190@checkpoint.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:47:28 -0000 On Mon, Nov 09, 2009 at 02:36:47PM +0200, Yoav Nir wrote: > On Nov 9, 2009, at 2:17 PM, Yair Elharrar wrote: > > >The proposed draft is intended to resolve an MITM attack scenario, > >but is the new extension tamper-resistant? > > It's as resistant as TLS is. > > >Since the MITM handles all traffic between the real client and real > >server, it could add a fake extension to the 2nd ClientHello with > >its original verify_data, and empty the returned extension in the > >ServerHello. > > The Finished messaged at the end of the TLS handshake signs all the > previous data. Unless the MITM can replicate the server's calculation > of the opaque_verify_data field, the client will notice that the > finished message is wrong (it signs an extension that the client did > not send). Indeed, the Finished message is the key. Note that there's no real need for the channel binding to actually be sent, as in EKR's proposed fix: there's only a need to include it as an extra input to the PRF call used to construct the Finished messages. However, by sending the channel binding data as a Hello extension, this proposal does the least amount of violence to existing implementations. Nico -- From djhopwood@googlemail.com Mon Nov 9 11:34:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEB13A68C1 for ; Mon, 9 Nov 2009 11:34:52 -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 XcWx9IAKISnl for ; Mon, 9 Nov 2009 11:34:51 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 875D63A6808 for ; Mon, 9 Nov 2009 11:34:51 -0800 (PST) Received: by ewy3 with SMTP id 3so3475199ewy.37 for ; Mon, 09 Nov 2009 11:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=YXX+nDs/3t3Tx2P3SJ2UO0Zlb0U26scKWlMNV/KdsIY=; b=dcryMtjd8sVU0YnoYh7GClqf9V4DmWD4m6XTkOYjzd5J3/nkEEYaoTL8a+4TA+EINn TQewx3xhh/rhCJxMwCN8dDPR/IlKYbL/qgl0Aw/CcWS9oIIxEX6+QYX3lRMmtAZyotnb kIc2I46zyjV0Hf8FlQBNMRcmFza0fuqY0QCyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=iOzz2Kj9FFT4tVxIfXZ9QwN6u0n3bnYiJSDEU1H64DNTtbzMGRLErCWwgK+6PutMTK Rx9vxPHg2VkPWesaHq3tDUSX/ogb0HkjWMKpYKRsNquElr4j+7tJRNiScb02FSo5U8Nt vAiSlC10lGRve9w7FYvpulODKsYNSVI8lx7z0= Received: by 10.213.96.65 with SMTP id g1mr9020447ebn.44.1257795314742; Mon, 09 Nov 2009 11:35:14 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 28sm11074eyg.6.2009.11.09.11.35.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 11:35:14 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF86EDF.3090004@jacaranda.org> Date: Mon, 09 Nov 2009 19:34:55 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AF81CFF.8010803@extendedsubset.com> In-Reply-To: <4AF81CFF.8010803@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1C8167277EE2EDDAD8B8FE2F" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:34:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C8167277EE2EDDAD8B8FE2F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > Yair Elharrar wrote: >> In addition, until such time that all clients in the world start >> supporting this extension (e.g. kiosks in airports), servers will >> have to support backward compatibility. >=20 > It will be a trade-off for each server admin to weigh and decide their > policy. I suspect many admins will prefer not to allow insecure > connections from unpatched airport kiosks. To prevent this attack, they don't have to disallow connections, only renegotiations in which the extension is not used. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig1C8167277EE2EDDAD8B8FE2F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr4bu8ACgkQWUc8YzyzqAdaNAD/YzgltWKVGMuHwr07lqkiTIA7 dJ1PRVwUlAxZZza1gb0A/inT0wDKG2jHUFGJD+2QkBLEWgG8rr09tx3TSUpaZdc+ =qJ6/ -----END PGP SIGNATURE----- --------------enig1C8167277EE2EDDAD8B8FE2F-- From djhopwood@googlemail.com Mon Nov 9 11:37:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3B328C1F3 for ; Mon, 9 Nov 2009 11:37:29 -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 Sqg6VrHdjgET for ; Mon, 9 Nov 2009 11:37:28 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id DB34B3A68C1 for ; Mon, 9 Nov 2009 11:37:27 -0800 (PST) Received: by ewy3 with SMTP id 3so3477982ewy.37 for ; Mon, 09 Nov 2009 11:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Ksxngh3CmZchHij0P8wVjaNjLPIkmERKuVb6CShrTP8=; b=J80u5ZMqtmyvPytyy5AXU5Y6OM+Dw9KB47i5dVTgfW1MwEQ/ufRTX0NPey4JQscPTs jCKJKNJX5Nh5VcSOuv6SCKSRGea6WOB5HsDr2GjJDJp5hJ19S5W1YgEWfbdSpG1X2DIV Fwr2j7Qwj5oO8qg+Mc7dy75UMGwYOTuf84Uh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Pf2INqbjbci6/mZrqTH18bNHL0H25XXw8SReGQQ5yaH5/g+6YYA1HjZy6PfwZsvGXp C9wluZPfAepKmAiXk5cLbdgWaNw5x4+pYycRP0ZHTXcD12I9kD28KHm18tMFtJJO2701 xiiuJEmQ4FiMbQFqkhH2NA6i+BWCDk1MTX+pg= Received: by 10.213.1.28 with SMTP id 28mr3767832ebd.70.1257795469265; Mon, 09 Nov 2009 11:37:49 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 5sm2725eyh.42.2009.11.09.11.37.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 11:37:48 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF86F8A.7090505@jacaranda.org> Date: Mon, 09 Nov 2009 19:37:46 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911091646.nA9GkW6n008821@fs4113.wdf.sap.corp> In-Reply-To: <200911091646.nA9GkW6n008821@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7F162FF9478CA06AEBFC7F86" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:37:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F162FF9478CA06AEBFC7F86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > There may be SSLv3 servers out there that choke on extension data > in the ClientHello. But that doesn't mean that one could not > upgrade SSLv3 servers to support TLS extensions. The more interesting > question is IMHO -- which TLS clients will choke when an SSLv3 server > returns a ServerHello extension? spec-wise, a ServerHello extension > is as unusual to SSLv3 as it is to TLSv1.0. Why would that situation arise? For that to happen, an SSL server library would have to be upgraded to support extensions but not to support TLS. Are there any SSL-only libraries being actively maintained? --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig7F162FF9478CA06AEBFC7F86 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr4b4oACgkQWUc8YzyzqAes0AD/abUOuRfH+GQUozzpkW1yM8bY NEx/yjA3dtK8je/PWssA/jvivIbGjDLB/f9k9pJ77CzWb8fxJXMUJP1vrA/yzkps =SjPS -----END PGP SIGNATURE----- --------------enig7F162FF9478CA06AEBFC7F86-- From Yair.Elharrar@audiocodes.com Mon Nov 9 11:46:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EDB3A676A for ; Mon, 9 Nov 2009 11:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 7OCmPolf7yU9 for ; Mon, 9 Nov 2009 11:46:46 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id 644043A657C for ; Mon, 9 Nov 2009 11:46:45 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.0.13]) by incoming.audiocodes.com with ESMTP; 09 Nov 2009 21:23:56 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80:0000:0000:0000:00d9:1fca:234.186.136.40]) by aclcas.corp.audiocodes.com ([10.1.0.13]) with mapi; Mon, 9 Nov 2009 21:47:42 +0200 From: Yair Elharrar To: David-Sarah Hopwood , "tls@ietf.org" Date: Mon, 9 Nov 2009 21:47:42 +0200 Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: Acphc9u7eUplOF1gQveGv8D+g/1dggAAHVlE Message-ID: References: <4AF81CFF.8010803@extendedsubset.com>, <4AF86EDF.3090004@jacaranda.org> In-Reply-To: <4AF86EDF.3090004@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:46:47 -0000 David-Sarah Hopwood wrote: >Marsh Ray wrote: >> Yair Elharrar wrote: >>> In addition, until such time that all clients in the world start >>> supporting this extension (e.g. kiosks in airports), servers will >>> have to support backward compatibility. >> >> It will be a trade-off for each server admin to weigh and decide their >> policy. I suspect many admins will prefer not to allow insecure >> connections from unpatched airport kiosks. > > To prevent this attack, they don't have to disallow connections, only > renegotiations in which the extension is not used. > That's a very good point. Perhaps the draft could be changed to reflect tha= t? I can't see any reason why an airport kiosk would need to renegotiate an HT= TPS connection (these devices rarely have client certificates installed); h= owever it should be allowed to connect to secure web sites. Yair -- This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message From mrex@sap.com Mon Nov 9 12:07:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BB73A676A for ; Mon, 9 Nov 2009 12:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 N3FzhUnpObMi for ; Mon, 9 Nov 2009 12:07:34 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 26CF83A68B4 for ; Mon, 9 Nov 2009 12:07:33 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA9K7xQN013801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 21:07:59 +0100 (MET) From: Martin Rex Message-Id: <200911092007.nA9K7w40024024@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Mon, 9 Nov 2009 21:07:58 +0100 (MET) In-Reply-To: <4AF86F8A.7090505@jacaranda.org> from "David-Sarah Hopwood" at Nov 9, 9 07:37:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:07:35 -0000 David-Sarah Hopwood wrote: > > Martin Rex wrote: > > There may be SSLv3 servers out there that choke on extension data > > in the ClientHello. But that doesn't mean that one could not > > upgrade SSLv3 servers to support TLS extensions. The more interesting > > question is IMHO -- which TLS clients will choke when an SSLv3 server > > returns a ServerHello extension? spec-wise, a ServerHello extension > > is as unusual to SSLv3 as it is to TLSv1.0. > > Why would that situation arise? For that to happen, an SSL server > library would have to be upgraded to support extensions but not to > support TLS. Are there any SSL-only libraries being actively > maintained? Yes, there are. But the issues do also affect TLS-capable servers and clients that talk to peers which are limited to SSLv3 only (through either configuration or implementation constraints). -Martin From yngve@opera.com Mon Nov 9 12:22:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1225E28C226 for ; Mon, 9 Nov 2009 12:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 zuzsr4vmyO9W for ; Mon, 9 Nov 2009 12:22:21 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id D5A9028C212 for ; Mon, 9 Nov 2009 12:22:20 -0800 (PST) Received: from acorna.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nA9KLc1D004193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 20:21:44 GMT Date: Mon, 09 Nov 2009 21:22:29 +0100 To: "David-Sarah Hopwood" , tls@ietf.org From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <200911091646.nA9GkW6n008821@fs4113.wdf.sap.corp> <4AF86F8A.7090505@jacaranda.org> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4AF86F8A.7090505@jacaranda.org> User-Agent: Opera Mail/9.65 (Win32) Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:22:22 -0000 On Mon, 09 Nov 2009 20:37:46 +0100, David-Sarah Hopwood wrote: > Martin Rex wrote: >> There may be SSLv3 servers out there that choke on extension data >> in the ClientHello. But that doesn't mean that one could not >> upgrade SSLv3 servers to support TLS extensions. The more interesting >> question is IMHO -- which TLS clients will choke when an SSLv3 server >> returns a ServerHello extension? spec-wise, a ServerHello extension >> is as unusual to SSLv3 as it is to TLSv1.0. > > Why would that situation arise? For that to happen, an SSL server > library would have to be upgraded to support extensions but not to > support TLS. Are there any SSL-only libraries being actively > maintained? This is unlikely to work, because at least some clients (Opera being one) will never send Extensions to SSL v3 server. In fact, Opera will not attempt Extensions to a server until it knows it is dealing with a TLS 1.0+ server, because we know there are TLS 1.0 servers that does not accept Extensions (see http://tools.ietf.org/html/draft-ietf-tls-interoperability-00 ). -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From marsh@extendedsubset.com Mon Nov 9 12:25:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7543A68F2 for ; Mon, 9 Nov 2009 12:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 V5ZUO7ux7-ex for ; Mon, 9 Nov 2009 12:25:57 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 08B0D3A68B4 for ; Mon, 9 Nov 2009 12:25:57 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7aoh-000KgB-1R for tls@ietf.org; Mon, 09 Nov 2009 20:26:23 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2C52B6678 for ; Mon, 9 Nov 2009 20:26:22 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19CLfEtE5sEYICT46OI4GO6fKJx4syksiE= Message-ID: <4AF87AE9.7090103@extendedsubset.com> Date: Mon, 09 Nov 2009 14:26:17 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4AF81CFF.8010803@extendedsubset.com>, <4AF86EDF.3090004@jacaranda.org> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:25:57 -0000 Yair Elharrar wrote: > David-Sarah Hopwood wrote: >> To prevent this attack, they don't have to disallow connections, >> only renegotiations in which the extension is not used. >> > > That's a very good point. Perhaps the draft could be changed to > reflect that? I can't see any reason why an airport kiosk would need > to renegotiate an HTTPS connection (these devices rarely have client > certificates installed); however it should be allowed to connect to > secure web sites. Here are some reasons to strongly encourage it: A variation of the attack involves the client seeing the renegotiation with MITM and the server sees just a single session. I believe but have not proven that this bug is not uncommon among typical clients. If TLS allows connections with anonymous servers (and possibly authenticated clients), then it violates the same identity guarantee implied by the spec. At some point in the future it will be a good indication that the client software is poorly-maintained. Some admins will prefer not to exchange confidential data with such systems. Absence of the extension will also raise flags on network monitoring equipment. Consistent usage will make detection more reliable. Here are some reasons not to encourage it so strongly: The attack in which the renegotiation is only seen on the client side usually requires a logic error on the client's part, so it might not be a concern of the TLS spec. Somewhere, someone is doing something over TLS that is not vulnerable because neither side ever will ever allow renegotiation. Unfortuantely, this can only be determined by direct inspection of the code at both ends. - Marsh From mrex@sap.com Mon Nov 9 12:35:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A80B3A6831 for ; Mon, 9 Nov 2009 12:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 N4jxhfeZf+8P for ; Mon, 9 Nov 2009 12:35:32 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2C60D3A680F for ; Mon, 9 Nov 2009 12:35:32 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA9KZvIR014232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Nov 2009 21:35:57 +0100 (MET) From: Martin Rex Message-Id: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Mon, 9 Nov 2009 21:35:57 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Subject: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:35:33 -0000 Maybe a patched Server (one with support for secure renegotiation) should ALWAYS assert this extension in a renegotiation TLS handshake _with_ the verify_data of both server.finished and client.finished in the ServerHello -- including when the client didn't send the extension (maybe because the client didn't dare confusing an SSLv3 server). If we recommend the Server to no longer perform insecure renegotiation, we could instead recommend that the server unconditionally asserts the ServerHello extension for the renegotiation handshake. This would even allow clients to agree to a secure renegotiation, which did not dare proposing it (because of an interoperability constraint with some legacy SSLv3 servers that choke on TLS extensions). Those clients that propose the secure renegotiation may need a fallback to a vanilla SSLv3 ClientHello. Such a fallback would have to be made at the apps level and is a significant change. Allowing server to assert this particular TLS extension in the ServerHello of a _renegotiation_handhshake_ without having received it in the ClientHello would obviate the need for the client to add a TLS extension to the ClientHello, and therefore may obviate the necessity of a re-connect fallback. -Martin From marsh@extendedsubset.com Mon Nov 9 12:44:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6CE3A68F8 for ; Mon, 9 Nov 2009 12:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 qH7m897Xqche for ; Mon, 9 Nov 2009 12:44:37 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 7871528C243 for ; Mon, 9 Nov 2009 12:44:20 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7b6U-000IPz-3O for tls@ietf.org; Mon, 09 Nov 2009 20:44:46 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 62E516678 for ; Mon, 9 Nov 2009 20:44:45 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19RlT0LD+Y3TikiUbHU34OhU6ozFEAcCKU= Message-ID: <4AF87F39.6080204@extendedsubset.com> Date: Mon, 09 Nov 2009 14:44:41 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> In-Reply-To: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:44:38 -0000 Martin Rex wrote: > Allowing > server to assert this particular TLS extension in the ServerHello > of a _renegotiation_handhshake_ without having received it in the > ClientHello What's going to check it? - Marsh From mrex@sap.com Mon Nov 9 12:58:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F6F3A6B78 for ; Mon, 9 Nov 2009 12:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 Z4Ejy74U5G5R for ; Mon, 9 Nov 2009 12:58:46 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4595F3A6A44 for ; Mon, 9 Nov 2009 12:58:45 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA9Kx8K7010089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 21:59:08 +0100 (MET) From: Martin Rex Message-Id: <200911092059.nA9Kx794027998@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Mon, 9 Nov 2009 21:59:07 +0100 (MET) In-Reply-To: <4AF87F39.6080204@extendedsubset.com> from "Marsh Ray" at Nov 9, 9 02:44:41 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:58:47 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > Allowing > > server to assert this particular TLS extension in the ServerHello > > of a _renegotiation_handhshake_ without having received it in the > > ClientHello > > What's going to check it? The client will have to check it, of course -- or abort with a handshake failure. It is not very nice to drop the entire responsibility on the client (which could be silently ignoring the server hello extension), I agree. Such a semantics would change an opt-in for secure renegotiation into an opt-out. The underlying scenario, that we are looking at, is that the server is asking the client whether it takes responsibility for the contents of the previous session. -Martin From ynir@checkpoint.com Mon Nov 9 13:05:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178A63A68A4 for ; Mon, 9 Nov 2009 13:05:37 -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 vqI2w28kU8im for ; Mon, 9 Nov 2009 13:05:36 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D64923A682D for ; Mon, 9 Nov 2009 13:05:35 -0800 (PST) X-CheckPoint: {4AF88127-1-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0491D29C005; Mon, 9 Nov 2009 23:05:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E223529C002; Mon, 9 Nov 2009 23:05:56 +0200 (IST) X-CheckPoint: {4AF88123-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA9L5uc6001480; Mon, 9 Nov 2009 23:05:56 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Nov 2009 23:06:00 +0200 From: Yoav Nir To: David-Sarah Hopwood , "tls@ietf.org" Date: Mon, 9 Nov 2009 23:05:59 +0200 Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: Acphc8xfMZxT+T1PTp6s68b8KNQpFAAC5+JZ Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> References: <4AF81CFF.8010803@extendedsubset.com>, <4AF86EDF.3090004@jacaranda.org> In-Reply-To: <4AF86EDF.3090004@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:05:37 -0000 David-Sarah Hopwood wrote: > Marsh Ray wrote: >> Yair Elharrar wrote: >>> In addition, until such time that all clients in the world start >>> supporting this extension (e.g. kiosks in airports), servers will >>> have to support backward compatibility. >> >> It will be a trade-off for each server admin to weigh and decide their >> policy. I suspect many admins will prefer not to allow insecure >> connections from unpatched airport kiosks. > > To prevent this attack, they don't have to disallow connections, only > renegotiations in which the extension is not used. Even that can be further refined. You can freely renegotiate an authenticat= ed session, as long as the renegotiation does not involve an identity chang= e. Obviously, if the first handshake include client authentication, any renego= tiation that includes the same client cert is fine. If the session is authenticated by the application (as in an HTTPS login pa= ge) it's also possible to renegotiate with impunity, but the interaction he= re between the application and the TLS layer may be too sensitive an bug pr= one to specify in the draft. For example, if an SSTP server renegotiates af= ter the client has authenticated (through PPP), I don't think there's a sec= urity risk in not implementing the extension. From mrex@sap.com Mon Nov 9 13:18:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AAC28C253 for ; Mon, 9 Nov 2009 13:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.092, 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 pT6jqJuQ+9BZ for ; Mon, 9 Nov 2009 13:18:56 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 8CC8928C1CF for ; Mon, 9 Nov 2009 13:18:56 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA9LJKAs000264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 22:19:21 +0100 (MET) From: Martin Rex Message-Id: <200911092119.nA9LJJe9029054@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Mon, 9 Nov 2009 22:19:19 +0100 (MET) In-Reply-To: <200911092059.nA9Kx794027998@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 9, 9 09:59:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:18:57 -0000 Martin Rex wrote: > > Marsh Ray wrote: > > > > Martin Rex wrote: > > > Allowing > > > server to assert this particular TLS extension in the ServerHello > > > of a _renegotiation_handhshake_ without having received it in the > > > ClientHello > > > > What's going to check it? > > The client will have to check it, of course -- or abort with > a handshake failure. > > It is not very nice to drop the entire responsibility on the client > (which could be silently ignoring the server hello extension), I agree. > Such a semantics would change an opt-in for secure renegotiation into > an opt-out. > > The underlying scenario, that we are looking at, is that the server > is asking the client whether it takes responsibility for the contents > of the previous session. Thinking about it, it is probably too daring to interpret the absence of an error as the confirmation of intent. How about an alternative HelloRequest, a "SecureHelloRequest", that signals to the client it is supposed to assert the secure renegotiation TLS extension on the renego ClientHello including the verify_data of the last client.finished or the server will abort the handshake. I'm wondering what a Server with an existing SSLv3 (0x03,0x00) session can do if it wants either a secure renegotiation or abort. Since SSLv3 does not define a "no_renegotiation" alert, a server that sends a HelloRequest and the determination to abort on insecure renegotiation could as well send a SecureHelloRequest in order to "encourage" a client that is only configured to send SSLv3 ClientHellos for maximum connectivity (and no app-level fallback). -Martin From mrex@sap.com Mon Nov 9 13:52:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEBA3A6970 for ; Mon, 9 Nov 2009 13:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 UMKg17XalREg for ; Mon, 9 Nov 2009 13:52: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 E0ABC3A68EF for ; Mon, 9 Nov 2009 13:52:08 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA9LqW9b028623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 22:52:32 +0100 (MET) From: Martin Rex Message-Id: <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Mon, 9 Nov 2009 22:52:31 +0100 (MET) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> from "Yoav Nir" at Nov 9, 9 11:05:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:52:10 -0000 Yoav Nir wrote: > > David-Sarah Hopwood wrote: > > > Marsh Ray wrote: > > > > To prevent this attack, they don't have to disallow connections, only > > renegotiations in which the extension is not used. > > Even that can be further refined. You can freely renegotiate an > authenticated session, as long as the renegotiation does not involve > an identity change. > > Obviously, if the first handshake include client authentication, > any renegotiation that includes the same client cert is fine. I whish there was a constraint that an identity/certificate that has been established for a party during the TLS handshake MUST not change during re-negotiation, but _none_ of the current SSL&TLS specs has such a constraint, so the issue of identity change is currently dumped as a responsibility onto the application. I am certainly in favour of locking this down for the renegotiation. I believe it is irresponsible to leave this un(der)specified as it is. We can be lucky if the application performs an authentication at all. since there currently is absolutely no signalling defined that would tell an application reliably at which point of the stream a renegotiation was completed, the app doesn't know (a) when to perform an additional authentication and (b) where the data from the previous session ends and where the next starts. As previously described in another message, the current spec has a requirement that additonal application data may be arbitrarily interleaved with a renegotiation handshake. I think this requirement makes a security assessment of the protocol impossible for changing identities. There are software architectures where the server certificate is checked in a callback style when processing the ServerCertificate handshake message (both: PKI-verification and server endpoint identification), Application data protected under the old encryption could be exchanged after the processing of the ServerCertificate and before the ChangeCipherSpec (i.e. protected under the old session), and also between ChangeCipherSpec and Finished messages (protected under the new session, but before the finished messages have verified). The semantics for the initial TLS handshake on a connection are *MUCH* cleaner (both full TLS handshake and session resume): no application data may be exchanged before the finished messages have been verified. Personally, I would it find much cleaner if the semantics for the renegotiation would require the TLS peers to suspend transmission of application data while performing TLS renegotiation, i.e. the client must not send any application data between ClientHello and the client's Finished message the server must not send any application data between ServerHello and either no_renegotiation alert or the server's Finished message the client must drop all application data received between ServerHello and either no_renegotiation alert or the server's Finished message the server must drop all application data received between the ClientHello and the client's Finished message Since the original streams in both directions could have been used in completely asynchronous fashion, both peers may have to get back in sync for the renegotiation, recognizing that they're in sync by receiving the first handshake message (ClientHello/ServerHello). Are there currently applications that actively abuse the possibility provided by the spec to interleave application data and handshake messages of a TLS renegotiation handshake (provided that the TLS implementation that (a) they're using and (b) they're talking to actually allow this. The fact that the spec says so, doesn't mean that everyone has implemented it in this fashion (since it is complex,difficult and possibly insecure)? -Martin From paul.hoffman@vpnc.org Mon Nov 9 13:55:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4710128C1E9 for ; Mon, 9 Nov 2009 13:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.093, 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 1HDUA4FsshO2 for ; Mon, 9 Nov 2009 13:55:55 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8444D3A695D for ; Mon, 9 Nov 2009 13:55:55 -0800 (PST) Received: from [133.93.128.35] (host-128-35.meeting.ietf.org [133.93.128.35]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nA9LuIvr093280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Nov 2009 14:56:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091109175954.8DF8F69E5CB@kilo.networkresonance.com> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> <4AF83FB9.9060302@drh-consultancy.demon.co.uk> <20091109175954.8DF8F69E5CB@kilo.networkresonance.com> Date: Tue, 10 Nov 2009 06:56:17 +0900 To: tls@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [TLS] Early code point assignment X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:55:56 -0000 At 9:59 AM -0800 11/9/09, Eric Rescorla wrote: >I don't think the problem here is really the code point assignment. Right: the problem is determining what that code point means. If there is an early assignment of code point Foo for draft-ietf-tls-frigmo-00.txt, and there is a bits-on-the-wire change in -01, what does Foo mean? Implementers will split between "it means the -00, get another code point" and "it means the latest version only". If you think this is a simple problem, you haven't seen the ragged history of the IETF in this regard. --Paul Hoffman, Director --VPN Consortium From marsh@extendedsubset.com Mon Nov 9 14:09:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088DA28C1E9 for ; Mon, 9 Nov 2009 14:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 gQmyjXDvaASO for ; Mon, 9 Nov 2009 14:09:46 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 2EE293A6968 for ; Mon, 9 Nov 2009 14:09:22 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7cQl-0009ah-0d; Mon, 09 Nov 2009 22:09:47 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 6698F6678; Mon, 9 Nov 2009 22:09:45 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/aAVnT9aAxVU+zgTTILdIFPpvIRwtZyo0= Message-ID: <4AF89325.3020905@extendedsubset.com> Date: Mon, 09 Nov 2009 16:09:41 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yoav Nir References: <4AF81CFF.8010803@extendedsubset.com>, <4AF86EDF.3090004@jacaranda.org> <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:09:47 -0000 Yoav Nir wrote: > > Even that can be further refined. You can freely renegotiate an > authenticated session, as long as the renegotiation does not involve > an identity change. Maybe. What about cases where the sessions are "authenticated" from the perspective of TLS, but the higher-layer protocols stack on additional notions of identity? I seem to recall systems (MS Terminal Services Gateway perhaps?) where a common client cert is used simply to grant basic access, then some form of HTTP authentication is used to authenticate which user it is. TLS does not necessarily know the full extent of "identity" attributed by higher layers, so you would be allowing any party that can pass the TLS level auth to MITM the others. For example, a browser may have several connections to the same set of servers behind https://ecommerce.example.com/, but you still wouldn't want to allow a bad guy on one to splice channels between them. > Obviously, if the first handshake include client authentication, any > renegotiation that includes the same client cert is fine. I disagree, I think it subtly violates the assumption of continuity over the TCP connection. > If the session is authenticated by the application (as in an HTTPS > login page) it's also possible to renegotiate with impunity, Renegotiation (in the absence of draft-rescorla-tls-renegotiate) offers a point which allows anyone who can pose as one of the parties (perhaps an anon) to splice in a connection from a third party to the one he is posing. This is bad, the HTTPS client-cert renego case. A---+---B C---+ A-Anonymous Alice B-Bob C-Client cert authenticated These are also bad: A---+---B C---+---B +---A2 (requires buggy client) A---+ C---+ A---+---B This violates core assumptions even if the same name or "anonymous" appears at each end of the multiple sessions at play. - Marsh From ekr@networkresonance.com Mon Nov 9 14:14:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5237628C275 for ; Mon, 9 Nov 2009 14:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.029 X-Spam-Level: X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5avUeFcmWr+s for ; Mon, 9 Nov 2009 14:14:06 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id D05C828C279 for ; Mon, 9 Nov 2009 14:14:04 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9F24569E672; Mon, 9 Nov 2009 14:15:12 -0800 (PST) Date: Mon, 09 Nov 2009 14:15:11 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091109221512.9F24569E672@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:14:08 -0000 At Mon, 9 Nov 2009 21:35:57 +0100 (MET), Martin Rex wrote: > > Maybe a patched Server (one with support for secure renegotiation) > should ALWAYS assert this extension in a renegotiation TLS handshake > _with_ the verify_data of both server.finished and client.finished > in the ServerHello -- including when the client didn't send the > extension (maybe because the client didn't dare confusing an SSLv3 server). This is forbidden by RFC 4366: servers can only send what the client offers: Note that for all extension types (including those defined in the future), the extension type MUST NOT appear in the extended server hello unless the same extension type appeared in the corresponding client hello. Thus clients MUST abort the handshake if they receive an extension type in the extended server hello that they did not request in the associated (extended) client hello. -Ekr From Nicolas.Williams@sun.com Mon Nov 9 14:52:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E097528C263 for ; Mon, 9 Nov 2009 14:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, 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 GvPfHvyNnv2i for ; Mon, 9 Nov 2009 14:52:54 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id E8FDE28C205 for ; Mon, 9 Nov 2009 14:52:53 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA9MrKX8007187 for ; Mon, 9 Nov 2009 22:53:20 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 nA9MrK4L027174 for ; Mon, 9 Nov 2009 15:53:20 -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 nA9MYIUa011903; Mon, 9 Nov 2009 16:34:18 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9MYIvT011902; Mon, 9 Nov 2009 16:34:18 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 9 Nov 2009 16:34:18 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091109223417.GK1105@Sun.COM> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:52:55 -0000 On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote: > I whish there was a constraint that an identity/certificate that has > been established for a party during the TLS handshake MUST not change > during re-negotiation, but _none_ of the current SSL&TLS specs has > such a constraint, so the issue of identity change is currently > dumped as a responsibility onto the application. > > I am certainly in favour of locking this down for the renegotiation. > I believe it is irresponsible to leave this un(der)specified as it is. +1 This is the right time to add such a constraint. I wouldn't be surprised if there are clients (for IMAP? LDAP?) that take advantage of this to allow the user to switch "hats" without reconnecting though. > As previously described in another message, the current spec has a > requirement that additonal application data may be arbitrarily > interleaved with a renegotiation handshake. I think this requirement > makes a security assessment of the protocol impossible for changing > identities. Or at least really difficult. > Personally, I would it find much cleaner if the semantics for the > renegotiation would require the TLS peers to suspend transmission > of application data while performing TLS renegotiation, > i.e. +1 This is the right time to add such a constraint. Unlike a "authenticated identities can't change" constraint, this could be implemented without conceivable app protocols being broken, I think, but it may require API changes for some implementations, and that it may put this change out of reach. Nico -- From marsh@extendedsubset.com Mon Nov 9 20:08:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DAB3A689E for ; Mon, 9 Nov 2009 20:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 D6EL400PvQNT for ; Mon, 9 Nov 2009 20:08:34 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id CD9A83A67EB for ; Mon, 9 Nov 2009 20:08:34 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7i2P-0002Bx-7A; Tue, 10 Nov 2009 04:09:01 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 699FA6678; Tue, 10 Nov 2009 04:08:58 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+26PqtpG74/0M/jF2y0zzbZIgH/cGyZ3s= Message-ID: <4AF8E755.5020208@extendedsubset.com> Date: Mon, 09 Nov 2009 22:08:53 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> In-Reply-To: <20091109223417.GK1105@Sun.COM> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:08:35 -0000 Nicolas Williams wrote: > On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote: >> I whish there was a constraint that an identity/certificate that has >> been established for a party during the TLS handshake MUST not change >> during re-negotiation, Hmm, few questions about that plan: Is this currently a defined concept in TLS: equivalence of identity? Isn't that one of the major uses of renegotiation? To change identity? That seems to be the entire point of the observed cases of renegotiation in https. Even if the only case we know of is a transition from an anonymous identity to a client-certified one, such a new constraint seems a bit pointless and likely to break someone. Perhaps you want to allow identities to be "strengthened" but not "weakened". Is this another new concept in TLS: are identities required to be partially- or fully-ordered? It's starting to sound like that question about ciphersuites being ordered according to strength. Would that make it illegal to resume a previous session over the same underlying connection if it could not be proven it was "the same" identity? What if the session's identity were strengthened? Could you end up in a situation where a session could be resumed on any of several other connections except the one on which it originated! - Marsh From djhopwood@googlemail.com Mon Nov 9 20:16:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8588828C0DE for ; Mon, 9 Nov 2009 20:16:17 -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 l9bzfSHNdSh3 for ; Mon, 9 Nov 2009 20:16:16 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id F31A73A6841 for ; Mon, 9 Nov 2009 20:16:15 -0800 (PST) Received: by ewy3 with SMTP id 3so3875745ewy.37 for ; Mon, 09 Nov 2009 20:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=sVmxQzmRSkKyPEkm9K1PnII+5nuBPSmAq2JdjKu91bA=; b=QogAqhTrit3kbWDef499I+11s2188FzlyPZP3zJjJhIsAtldTMity5hKp7mcwjQAfM Sa3UQ4aMHwiHA1NLfHh52UdGEeDRP5Hl7omqXif0O/6MwNeyUuuHYJGo9JBT25VNTEPR PQAqFIuQ1BniY0qz3UAVGHvhWI931JASHttzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=TmayfrmpWUkCEMt7gCZI0lmiaiqbX0VQZy8f7sm1I2C05ORa5NjS1QG8Ty6Qqelynk tuCu36dY5Y++jxEodTbEMDyGXXj/Az9+xrD024FNwVvjD4WhBiZ8FvSj75nL6KGzZYk0 pZDwfkcVa3RQReX7uZJP6WbydMgD0AeTOFt5I= Received: by 10.213.25.66 with SMTP id y2mr4353446ebb.97.1257826602451; Mon, 09 Nov 2009 20:16:42 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 5sm822346eyf.31.2009.11.09.20.16.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 20:16:41 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF8E8EB.5010508@jacaranda.org> Date: Tue, 10 Nov 2009 04:15:39 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AF81CFF.8010803@extendedsubset.com>, <4AF86EDF.3090004@jacaranda.org> <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigAFA9CDD743916563EBFD3ADB" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:16:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAFA9CDD743916563EBFD3ADB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > David-Sarah Hopwood wrote: >> Marsh Ray wrote: >>> Yair Elharrar wrote: >>>> In addition, until such time that all clients in the world start >>>> supporting this extension (e.g. kiosks in airports), servers will >>>> have to support backward compatibility. >>> It will be a trade-off for each server admin to weigh and decide thei= r >>> policy. I suspect many admins will prefer not to allow insecure >>> connections from unpatched airport kiosks. >> To prevent this attack, they don't have to disallow connections, only >> renegotiations in which the extension is not used. >=20 > Even that can be further refined. You can freely renegotiate an > authenticated session, as long as the renegotiation does not involve an= > identity change. I don't agree. In order for the security properties that are supposed to be provided by TLS to be preserved, the client in the renegotiated session must be able to prove cryptographically that it knows some secret= that was associated with the previous session, *and* that it intends this= session to be a continuation of that one. The only practical way to do that is with the extension. In particular, "any renegotiation that includes the same client cert" is not fine. If the private key to a given client cert is compromised, that should only allow an attacker who knows it to authenticate with that cert= ; it should not allow them to attack the sessions of the original cert holder. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigAFA9CDD743916563EBFD3ADB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr46PQACgkQWUc8YzyzqAf7kAD9EzpK0gRCRbhH/E/wsKS/+V30 VZZqHY1IKTzrmFb3Ow8A/11apiVIofQ73N+900KV484Sg6OjJuj0a+yDxFox+Tft =hjAk -----END PGP SIGNATURE----- --------------enigAFA9CDD743916563EBFD3ADB-- From djhopwood@googlemail.com Mon Nov 9 20:44:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEB23A69CF for ; Mon, 9 Nov 2009 20:44: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 PmeO1yRzz73g for ; Mon, 9 Nov 2009 20:44:46 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id A4B143A696F for ; Mon, 9 Nov 2009 20:44:41 -0800 (PST) Received: by ewy3 with SMTP id 3so3886848ewy.37 for ; Mon, 09 Nov 2009 20:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=ZEWF9hqtuC3yj3dhY0iKGuXUmjcwoz0JVo3SbIiDF9c=; b=a3JZskwqkQNl+1WzH7Sg8qudQVByKSvwUA4jUo6vLwGUT2Oz0fZtlqDkQrAjpHHqHo VCnn6q22v5VFQM0wC+unuN+NIE8PLAp7l9WCMHD5dmuQs5yDCHz2g1v8zBeVfzuMsWAy XdAstpYvE/do+tFZwbOsU+9Qn3A/NNOVq7SEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=gdFE6W2SiTmL4IGmToL26PMM7eMAQsVql5F00ueRgjY66HgBpIKw99d/UYln2XhYNB t0flgilNhaYRUuCmX1dgqFMViwd8c1h8P16zR3u/r6e4ONwQwHkGi23runYcczFJm6jb XeflFpPHJ2cCR3z31BAJW1MNP1gAbOyc6oOm4= Received: by 10.213.25.79 with SMTP id y15mr9954102ebb.78.1257828305341; Mon, 09 Nov 2009 20:45:05 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 28sm842278eyg.46.2009.11.09.20.45.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 20:45:04 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF8EF8F.3090100@jacaranda.org> Date: Tue, 10 Nov 2009 04:43:59 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> In-Reply-To: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigDD56E015EA3A4EBC61CFE247" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:44:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDD56E015EA3A4EBC61CFE247 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Maybe a patched Server (one with support for secure renegotiation) > should ALWAYS assert this extension in a renegotiation TLS handshake > _with_ the verify_data of both server.finished and client.finished > in the ServerHello -- including when the client didn't send the > extension (maybe because the client didn't dare confusing an SSLv3 serv= er). >=20 > If we recommend the Server to no longer perform insecure renegotiation,= > we could instead recommend that the server unconditionally asserts the > ServerHello extension for the renegotiation handshake. That's not necessary. Suppose that the client sent an SSLv3 ClientHello with client_version =3D 3.1 (or higher). Assuming the server supports TLS= , then TLS will be negotiated. So when the client sends the renegotiation, it knows that it is safe to send extensions. The attack is prevented as long as the renegotiating handshake uses the extension; it is not necessa= ry for the initial handshake to have used it. However, the draft is not clear enough on that last point. It should clarify that, while including a zero-length Renegotiation_Info implies that the extension is supported (by either the client or server), the converse is not true: lack of a Renegotiation_Info extension on the first= handshake does not imply that the extension isn't supported. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigDD56E015EA3A4EBC61CFE247 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr475cACgkQWUc8YzyzqAcTWAD7BJZGYBQIO/J1VOgfNaEzCEAb /gOocr/bIX1UgIcmmIsA/3ivMXoZmFfcQJuoLdEeahd0nEgwqn7POAdM5JyWaOCe =v6/z -----END PGP SIGNATURE----- --------------enigDD56E015EA3A4EBC61CFE247-- From mike-list@pobox.com Mon Nov 9 20:58:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1FD3A6915 for ; Mon, 9 Nov 2009 20:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 8hrMXqhfBYd9 for ; Mon, 9 Nov 2009 20:58:46 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id E8F253A67CF for ; Mon, 9 Nov 2009 20:58:44 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C86CA7A389 for ; Mon, 9 Nov 2009 23:59:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=6Rv8739VjmaQ gELgB8HyuNRiN2g=; b=wisd/c9ybgAUfwPuCvWQbbtBKRcAHcnq25lT1FrNWjSZ PmsvuUZbRsRpv+cJJQBjZoNiA3JCiODEMScn43pNWmUIbFmMkwDx8VMX509B1tc7 d76BfIlq9dSUJZCW8ZzIIh3KE/ytgbJq0YfwX0YzlKuV2QEsQsExZcypzWR6j4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=DB8Oo8 uX0Uq/Jv2X5RCHgm5uAcMP4DYuXXK92jnAlvEprl9Yf4f5EDX8lM92M0GWKF6D6s /KDQEaFVGshqLuh3L1dHkZLLTcmAHnO5BlKvdcOmtmMbm5rA8unDe6khQrWOtifV NmgZ2NB2daTbloVl6v3XVO7zxgU5V5ocTAUZw= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C5D977A388 for ; Mon, 9 Nov 2009 23:59:10 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 3A81E7A387 for ; Mon, 9 Nov 2009 23:59:10 -0500 (EST) Message-ID: <4AF8F363.2030201@pobox.com> Date: Mon, 09 Nov 2009 21:00:19 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> In-Reply-To: <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: C8AF8E54-CDB5-11DE-A7B1-7B3EEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:58:47 -0000 > As previously described in another message, the current spec has a > requirement that additonal application data may be arbitrarily > interleaved with a renegotiation handshake. I think this requirement > makes a security assessment of the protocol impossible for changing > identities. If your TLS API was able to tell you exactly where in the application data stream a renegotiation has completed successfully, you would be able to apply the original security parameters to the data received prior to the renegotiation, and then switch to the new parameters for the data received after the renegotiation. That would catch the MITM attack being discussed now. > Personally, I would it find much cleaner if the semantics for the > renegotiation would require the TLS peers to suspend transmission > of application data while performing TLS renegotiation, > i.e. > > the client must not send any application data between > ClientHello and the client's Finished message > > the server must not send any application data between > ServerHello and either no_renegotiation alert or > the server's Finished message > > the client must drop all application data received > between ServerHello and either no_renegotiation alert > or the server's Finished message > > the server must drop all application data received > between the ClientHello and the client's Finished message When I first implemented TLS, the only reason I could envision for renegotiation was to refresh the symmetric keys, so I made it work asynchronously. I wrote about it in this message: http://www.ietf.org/mail-archive/web/tls/current/msg04042.html With this design, application data can flow at nearly full speed while a renegotiation is taking place. Requiring all data to stop flowing during a renegotiation, may be unnecessary in some situations. I do see however, that data probably needs to stop flowing after sending a Finished message until receiving the peer's Finished message, but that affects only one direction and last for one round trip, not two. When you add changing client credentials to the mix, then data flow probably has to stop, but that is really an application-level decision. Also silently dropping data never seems like the right thing to do IMHO. > Are there currently applications that actively abuse the possibility > provided by the spec to interleave application data and handshake > messages of a TLS renegotiation handshake (provided that the > TLS implementation that (a) they're using and (b) they're talking > to actually allow this. The fact that the spec says so, doesn't > mean that everyone has implemented it in this fashion (since it > is complex,difficult and possibly insecure)? Yes, see the above referenced message. But I don't agree that it's abuse since that is what the spec. says to do. Mike From mike-list@pobox.com Mon Nov 9 21:17:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3D263A67F7 for ; Mon, 9 Nov 2009 21:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 eQCTlCyuPDmT for ; Mon, 9 Nov 2009 21:17:12 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id C34113A6A45 for ; Mon, 9 Nov 2009 21:17:12 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BE29E7A500 for ; Tue, 10 Nov 2009 00:17:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=PeqMve7JU6Ju LPDLgtxJS/FDgyg=; b=Y9qo7LcTqH7rdrNfAgPFRYPCmbbgZ+C3Wh8tnrqhTgcC Qw08AsgSQtvbTYIHi79QKTjGrZGJLD3ml4/BcLGx/nzYbTYUT6bl5C8FtYjoeE3a 4KFq73w41XH2GCwyIUWiYg6EyxAQBx947fbrtbq0i+trV1B5JO3jbMYIxBCrTpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=uZLzyt knGzAF74CU5y+s5KmfTi50vYtSc0p+o3747czhGDvMjGTHhrbYf+rapLc84yA4Bx e8oQJbQ3wBGGzKmNHkBr0M6gA7t8UIMRH1DKWlf/ntH7AaCIDzTyhCVU+QF/Tsn8 jLjiQGyRxEDaZjO+DffJTTRsNZWLo6YdKwba0= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BA6C47A4FE for ; Tue, 10 Nov 2009 00:17:39 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 62E787A4FD for ; Tue, 10 Nov 2009 00:17:39 -0500 (EST) Message-ID: <4AF8F7B4.7020101@pobox.com> Date: Mon, 09 Nov 2009 21:18:44 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> In-Reply-To: <4AF8EF8F.3090100@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 5DB28B8A-CDB8-11DE-B448-7B3EEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:17:13 -0000 > Suppose that the client sent an SSLv3 ClientHello > with client_version = 3.1 (or higher). Assuming the server supports TLS, > then TLS will be negotiated. So when the client sends the renegotiation, > it knows that it is safe to send extensions. The attack is prevented as > long as the renegotiating handshake uses the extension; it is not necessary > for the initial handshake to have used it. The problem is that your initial handshake *is* the renegotiation! (from the server's point of view) A client needs to send an empty Renegotiation_Info so that the server can ascertain whether an attack is taking place. Otherwise it may be configured to let you "re"negotiate for practical reasons, and you just bought someone a pizza. The scary thing is that a truly paranoid client can't connect to any unpatched server that asks for credentials immediately. Mike From djhopwood@googlemail.com Mon Nov 9 21:44:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716353A68B0 for ; Mon, 9 Nov 2009 21:44:48 -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 BdBuHZ7C6mbp for ; Mon, 9 Nov 2009 21:44:47 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 7D2493A6A34 for ; Mon, 9 Nov 2009 21:44:22 -0800 (PST) Received: by ewy3 with SMTP id 3so3909199ewy.37 for ; Mon, 09 Nov 2009 21:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Pgzqtj3hBliM1mXTXfNCUymrQVUccxUyvY19wFTU02g=; b=MwPyiU/QD1ycVVnCirICbeBGB6CXzIF9AMvcaJBCKCMknW624EpyP/jMLuN9wqGkeA u9EQNkL2FPYMAaGFEH6Yfl/vH7SyQBHQNPMZGf0BxxuryHouIsFcdJeq+nr6o6uct0Ls fuVvj/3KTnaUlcfbhrcsFn19yP2bnB92bM7N0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=wfE6XMV08sxmXUEUVzy7Sk7FoVr8Ug0LcdUpqnXM9uA7aERAnwcQBSe/pNvyOvoyYd /iaTHutKcz8Ixpz09Exb5XgERJAtmLKPY8zBdUTcUTgJZIim/2xlNd/10X76eNqPQvFD HcX+BN7X7u16U2bf9OYQsXDOJUWBUjm2bMH9g= Received: by 10.216.88.67 with SMTP id z45mr1394474wee.112.1257831886123; Mon, 09 Nov 2009 21:44:46 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 10sm892056eyd.6.2009.11.09.21.44.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 21:44:45 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF8FDBD.4080003@jacaranda.org> Date: Tue, 10 Nov 2009 05:44:29 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> In-Reply-To: <4AF8F7B4.7020101@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3157A5274D05D145550F90AB" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:44:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3157A5274D05D145550F90AB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: >> Suppose that the client sent an SSLv3 ClientHello >> with client_version =3D 3.1 (or higher). Assuming the server supports = TLS, >> then TLS will be negotiated. So when the client sends the renegotiatio= n, >> it knows that it is safe to send extensions. The attack is prevented a= s >> long as the renegotiating handshake uses the extension; it is not >> necessary for the initial handshake to have used it. >=20 > The problem is that your initial handshake *is* the renegotiation! > (from the server's point of view) I may well be confused, but: a handshake is a renegotiation if-and-only-i= f it is encrypted. Initial handshakes are in the clear. So there is no ambiguity, from either party's point of view, about whether a handshake is a renegotiation. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig3157A5274D05D145550F90AB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr4/csACgkQWUc8YzyzqAeeuQD+PPrqXCqkyBwYr8V/BXldDcEd +g5p+Q5wSd9XTAeg9UYA/0zNLEmJHg435JuQhKbm73S7sEWbuorcD4jLwvQ8PN9V =WMwd -----END PGP SIGNATURE----- --------------enig3157A5274D05D145550F90AB-- From djhopwood@googlemail.com Mon Nov 9 21:52:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7F728C0F4 for ; Mon, 9 Nov 2009 21:52:43 -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 84P6Rs7484BB for ; Mon, 9 Nov 2009 21:52:43 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id EE1C128C0F2 for ; Mon, 9 Nov 2009 21:52:42 -0800 (PST) Received: by ewy3 with SMTP id 3so3912201ewy.37 for ; Mon, 09 Nov 2009 21:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=iKWD5d2MU1P6HDrvUHHRs9JCUiGngeaR1e5EWmQWh1U=; b=Lqq4AV5puFeyiQ06jQtPCG+Fh/OVmMMMDTOUlb3bp3iRmlY2topWH/5bHkY8MAHTYE 8psFJvOXDVLPvYtbLP+mR5VAsa3ZFaq1fgpKNzHr/IG6Dhcb8i7Ob+UgzsA9bl1v8KUy vqLkT19ffi9ZRhHbNuG258uxMv7J1CaZhjuwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=kfUc92nseG+apJ+J2rYu/2q9t68zH2+EhVZ1xnnXaNKxWFakDR6AzYZ15kJBtKtiIS GeCNMvhPTq/I6O4seXhsqrRBcQWyHywlK5r2626lwGEEgZmjbIGPb+DrdJ3lKAbbE9fg VYZ2Px4u4iYrjJpMO9VU5XxldK9nWoNk5bWt0= Received: by 10.213.23.204 with SMTP id s12mr595499ebb.69.1257832385174; Mon, 09 Nov 2009 21:53:05 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 23sm945238eya.28.2009.11.09.21.53.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 21:53:04 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF8FFBC.8040005@jacaranda.org> Date: Tue, 10 Nov 2009 05:53:00 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> In-Reply-To: <4AF8FDBD.4080003@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig720507818261933C755F5212" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:52:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig720507818261933C755F5212 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Michael D'Errico wrote: >>> Suppose that the client sent an SSLv3 ClientHello >>> with client_version =3D 3.1 (or higher). Assuming the server supports= TLS, >>> then TLS will be negotiated. So when the client sends the renegotiati= on, >>> it knows that it is safe to send extensions. The attack is prevented = as >>> long as the renegotiating handshake uses the extension; it is not >>> necessary for the initial handshake to have used it. >> The problem is that your initial handshake *is* the renegotiation! >> (from the server's point of view) >=20 > I may well be confused, but: a handshake is a renegotiation if-and-only= -if > it is encrypted. Well, except when the ciphersuite specifies no encryption. I should have said "if-and-only a ciphersuite other than TLS_NULL_WITH_NULL_NULL is in effect". > Initial handshakes are in the clear. So there is no > ambiguity, from either party's point of view, about whether a handshake= > is a renegotiation. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig720507818261933C755F5212 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr4/7wACgkQWUc8YzyzqAfuMwD+JaIjQYE1ddAeevixYIvletTl CF6x++FaM9jgrqdl/0MA/RvFqkfuRo9pFzmH+MDWArRQ6JE6CfKrzMV88Hsat/rv =bqzp -----END PGP SIGNATURE----- --------------enig720507818261933C755F5212-- From mike-list@pobox.com Mon Nov 9 21:59:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E56428C0D7 for ; Mon, 9 Nov 2009 21:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 UPBfQTHDpuEh for ; Mon, 9 Nov 2009 21:59:36 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 3631A28C119 for ; Mon, 9 Nov 2009 21:59:22 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E9C8A99274 for ; Tue, 10 Nov 2009 00:59:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=OYhFBwIjfeMi 9Boa58N5GL50A+4=; b=xeSGNm8tR3lUY0vIQgr6OBwnuw+doQbApbynVZK6gbE2 py76m7PgXy0BZ4DiqEedwm8XMi8gwAklX5cRcYQWc0/knk32QoVI/8Umf19z9mdu RDD/lF3YhC04UJe+AlcYXzagHzyXPMJAyDGuFLuy8hGFEbHHdFLw13caXdOIzv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=t1D4P6 Fq/skzEyJUSPGc997EgzyO53scTc8FDLHMKOLNepcBhznL3a2mXMyrlO+Hlbnvbv txTUChm1e0qqIy9lrDo2pshh5ex5lrVfPxoPnCJHeiPqTFqsLp9icCvxGkU27/2O llNKvPDrclmwcFbTccBZEdArEiL6XqkuzfDWg= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id DE35299273 for ; Tue, 10 Nov 2009 00:59:48 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 7A60999272 for ; Tue, 10 Nov 2009 00:59:48 -0500 (EST) Message-ID: <4AF90198.6010505@pobox.com> Date: Mon, 09 Nov 2009 22:00:56 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> In-Reply-To: <4AF8FDBD.4080003@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 412D4986-CDBE-11DE-8474-BD45BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:59:37 -0000 >> The problem is that your initial handshake *is* the renegotiation! >> (from the server's point of view) > > I may well be confused, but: a handshake is a renegotiation if-and-only-if > it is encrypted. Initial handshakes are in the clear. So there is no > ambiguity, from either party's point of view, about whether a handshake > is a renegotiation. Your initial handshake is in the clear from you to the MITM, but it gets sent over the already-secure connection from the MITM to the server, so from the server's perspective you are renegotiating. This is why you have to send the Renegotiation_Info extension -- it let's the server know that *you* think you are performing an initial handshake. It can then shut down the connection and save you from the attack. Mike From djhopwood@googlemail.com Mon Nov 9 22:24:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8643D3A693C for ; Mon, 9 Nov 2009 22:24:07 -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 lbwgN+GBAbyH for ; Mon, 9 Nov 2009 22:24:06 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 1C95A3A6899 for ; Mon, 9 Nov 2009 22:24:05 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so332443eyf.51 for ; Mon, 09 Nov 2009 22:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=5jLpQXjD+u2BqhgVdKA/j4IeAP7Gf52BV41vt6mEv6g=; b=jPSEGx403NSCW+qI/XQMtQ5lkuwhwDNjd7quLTgj4sdXmE8fM91ZehCnddnvwi7lBS wuLEgrUgMi297i+wG6mK98i+BCnMDY10QEG1WPzJUZjheb7jion101SMyCzqBCM8ijYC u2VlrduQ9hBnN4vtjWqq8XIyMJiyehG+sHE9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=MnBGWPpNJNvnRzaWys45Hzu+M3S25F31nzvGvX/99TKrhlJ/ka+GBr5o4fWk+Uk+xd eQpLAbjv8E43frlnyPRGRl7sIWL/SA/SIQLJKS4552yCMUSbKchJTdZm/i7Bz8BVreRQ u8lms/bq8c4xTIu/JPToOjktcUz89C0+OIq0E= Received: by 10.213.0.151 with SMTP id 23mr4443069ebb.43.1257834269264; Mon, 09 Nov 2009 22:24:29 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 24sm984531eyx.45.2009.11.09.22.24.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 22:24:28 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF9070E.4050305@jacaranda.org> Date: Tue, 10 Nov 2009 06:24:14 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> In-Reply-To: <4AF8FDBD.4080003@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF60FE6B14EA87530861FF446" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:24:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF60FE6B14EA87530861FF446 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Michael D'Errico wrote: >>> Suppose that the client sent an SSLv3 ClientHello >>> with client_version =3D 3.1 (or higher). Assuming the server supports= TLS, >>> then TLS will be negotiated. So when the client sends the renegotiati= on, >>> it knows that it is safe to send extensions. The attack is prevented = as >>> long as the renegotiating handshake uses the extension; it is not >>> necessary for the initial handshake to have used it. >> The problem is that your initial handshake *is* the renegotiation! >> (from the server's point of view) >=20 > I may well be confused, but: a handshake is a renegotiation if-and-only= -if > it is encrypted. Initial handshakes are in the clear. So there is no > ambiguity, from either party's point of view, about whether a handshake= > is a renegotiation. Actually this is not quite right, although not in a way that affects my main point. A handshake is a renegotiation from the server's point of view if-and-only-if a ciphersuite other than TLS_NULL_WITH_NULL_NULL is in effect. It is possible that an initial handshake by a client that was sent in the clear, could be encrypted by an attacker and appear to the server as a renegotiation. In that case, the server can reject the renegotiation if the ClientHello doesn't contain a correct (and non-empty= ) Renegotiation_Info. It is also possible that, if a client that does not support the extension= requests a renegotiation on a session with the attacker, then the attacke= r can decrypt it and present it to the server as an initial handshake. But this only applies to clients that do not support the extension at all= =2E If a client does support it and sends it only when renegotiating, then this variant of the attack is still prevented. So, I was right in my original statement that "the attack is prevented as long as the renegotiating handshake uses the extension." Note that both clients and servers must avoid renegotiating without using the extension; it isn't sufficient for only servers to avoid doing so. As long as that is the case, for a client does support the extension, failing to send the zero-length Renegotiation_Info in an initial handshak= e does not enable an attack. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigF60FE6B14EA87530861FF446 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr5BxUACgkQWUc8YzyzqAdbtwD/Xu6b9bB4KzwXHgbaMWIvQRSl nA+Yc8zeRhOqhD3AEhMA/21uPkcuwDsmWSBT8Ypb6h7uQFfHLKEfWExM6ciJhw+F =LEoO -----END PGP SIGNATURE----- --------------enigF60FE6B14EA87530861FF446-- From djhopwood@googlemail.com Mon Nov 9 22:33:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726FB3A6899 for ; Mon, 9 Nov 2009 22:33:31 -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 he-zG1-nab8Z for ; Mon, 9 Nov 2009 22:33:30 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 12D0B3A6833 for ; Mon, 9 Nov 2009 22:33:29 -0800 (PST) Received: by ewy3 with SMTP id 3so3928013ewy.37 for ; Mon, 09 Nov 2009 22:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Qk0Hi7EI7t8Nj+DTWMU1RhSjOELPN1fevbzZ8FL86RU=; b=CpoO4dEvLRUzVaH4jQBcFNxDxi8X12iQdLJHz0SeIrz9zBpuMmb/uxdqTsBD1LsK1n 5jQBwV4zwFJHGwfKzE5p7jgYXahDNGkZDTs0j0x6TgEdWhCJ/LBmAFT/HZzPQ7VLRv6M Wg0QA3z+ob/LyuL3Qg7GxqvA2PhTf/A2q/FiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Vq7xIaBN7S6G9N6z/7WEJidA01PhAoWG5RkLvAHqOec4L6fONvavpYEoijBNLcGwUD dmtgJkGc48Eo0i+sb6hxdLpt4emzbdq320oftmILrfpgl0pnSeKYuPNyWWbnoOiSOKhR Ncgo/Z7/bvsU5XH0kzDk+Opt3w6051LII8BFw= Received: by 10.216.87.3 with SMTP id x3mr632649wee.132.1257834830990; Mon, 09 Nov 2009 22:33:50 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 10sm4265758eyd.4.2009.11.09.22.33.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 22:33:50 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF90946.3020104@jacaranda.org> Date: Tue, 10 Nov 2009 06:33:42 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF90198.6010505@pobox.com> In-Reply-To: <4AF90198.6010505@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigCCF8A6BA195DDF1A106D0EB0" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:33:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCCF8A6BA195DDF1A106D0EB0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: >>> The problem is that your initial handshake *is* the renegotiation! >>> (from the server's point of view) >> >> I may well be confused, but: a handshake is a renegotiation >> if-and-only-if it is encrypted. Initial handshakes are in the clear. >> So there is no ambiguity, from either party's point of view, about >> whether a handshake is a renegotiation. >=20 > Your initial handshake is in the clear from you to the MITM, but it get= s > sent over the already-secure connection from the MITM to the server, so= > from the server's perspective you are renegotiating. This is why you > have to send the Renegotiation_Info extension -- it let's the server > know that *you* think you are performing an initial handshake. It can > then shut down the connection and save you from the attack. If from the server's perspective you are renegotiating, and it doesn't se= e a non-empty and correct Renegotiation_Info, then it should shut down the connection anyway. The server doesn't need to know whether the client supports the extension; to avoid the attack, it has to shut down the connection whether the client supports the extension or not. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigCCF8A6BA195DDF1A106D0EB0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr5CUYACgkQWUc8YzyzqAfPjgD+LzjXT0U0bsGgTkEoLzJq1B4v q+EMxKZG+9mXBiR9qo8A/jv/K/B1GL44X9t6zIJBnP2mAex0PXcxXbBVZIXVLcXp =ye9T -----END PGP SIGNATURE----- --------------enigCCF8A6BA195DDF1A106D0EB0-- From zkanghon@hotmail.com Mon Nov 9 22:51:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1010A3A6927 for ; Mon, 9 Nov 2009 22:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ1DZt3hWuAL for ; Mon, 9 Nov 2009 22:51:53 -0800 (PST) Received: from snt0-omc3-s9.snt0.hotmail.com (snt0-omc3-s9.snt0.hotmail.com [65.55.90.148]) by core3.amsl.com (Postfix) with ESMTP id 3E8ED3A6824 for ; Mon, 9 Nov 2009 22:51:53 -0800 (PST) Received: from SNT102-W8 ([65.55.90.137]) by snt0-omc3-s9.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 22:52:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ff81266f-8b0d-46ee-ba16-f88af7ca2011_" X-Originating-IP: [58.185.114.117] From: Zheng Kanghong To: Date: Tue, 10 Nov 2009 14:52:20 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2009 06:52:20.0084 (UTC) FILETIME=[59303B40:01CA61D2] X-Mailman-Approved-At: Tue, 10 Nov 2009 06:41:18 -0800 Subject: [TLS] TLS Renegotiation - Any implications to EAP-TLS ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:52:45 -0000 --_ff81266f-8b0d-46ee-ba16-f88af7ca2011_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi all, Anyone discussed the implications of the TLS renegotiation vulnerability to EAP-TLS? >From my little understanding, it seems like EAP-TLS is not vulnerable. There is no application layer protocol involved when EAP-TLS is executed [Please correct me if I'm wrong].If client certificate authentication is required (it should), the server will always request for client certificates.After a successful EAP-TLS exchange, the TLS tunnel is not used; only the keying material is exported [Although the tunnel is not used, is it still present and can be used in some way? Or is there no state information stored for the EAP method after a successful EAP exchange?).EAP re-authentication is a new EAP exchange which is independent of the previous exchange. It is not the same as TLS renegotiation which is executed in the previous TLS tunnel. Any comments? Thanks. - kh _________________________________________________________________ New Windows 7: Find the right PC for you. Learn more. http://windows.microsoft.com/shop --_ff81266f-8b0d-46ee-ba16-f88af7ca2011_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi all,

Anyone discussed the implications of the TLS renegotiation vulnerability to EAP-TLS?

From my little understanding, it seems like EAP-TLS is not vulnerable.

  • There is no application layer protocol involved when EAP-TLS is executed [Please correct me if I'm wrong].
  • If client certificate authentication is required (it should), the server will always request for client certificates.
  • After a successful EAP-TLS exchange, the TLS tunnel is not used; only the keying material is exported [Although the tunnel is not used, is it still present and can be used in some way? Or is there no state information stored for the EAP method after a successful EAP exchange?).
  • EAP re-authentication is a new EAP exchange which is independent of the previous exchange. It is not the same as TLS renegotiation which is executed in the previous TLS tunnel.

Any comments? Thanks.
- kh

New Windows 7: Find th e right PC for you. Learn more. --_ff81266f-8b0d-46ee-ba16-f88af7ca2011_-- From ekr@networkresonance.com Tue Nov 10 06:48:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F0128C1DB for ; Tue, 10 Nov 2009 06:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxFJvQ91c+ut for ; Tue, 10 Nov 2009 06:48:38 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 75F8928C1D3 for ; Tue, 10 Nov 2009 06:48:38 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 43E2B69E83D; Tue, 10 Nov 2009 06:49:51 -0800 (PST) Date: Tue, 10 Nov 2009 06:49:50 -0800 From: Eric Rescorla To: David-Sarah Hopwood In-Reply-To: <4AF8FDBD.4080003@jacaranda.org> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091110144951.43E2B69E83D@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:48:39 -0000 At Tue, 10 Nov 2009 05:44:29 +0000, David-Sarah Hopwood wrote: > > [1.1 ] > Michael D'Errico wrote: > >> Suppose that the client sent an SSLv3 ClientHello > >> with client_version = 3.1 (or higher). Assuming the server supports TLS, > >> then TLS will be negotiated. So when the client sends the renegotiation, > >> it knows that it is safe to send extensions. The attack is prevented as > >> long as the renegotiating handshake uses the extension; it is not > >> necessary for the initial handshake to have used it. > > > > The problem is that your initial handshake *is* the renegotiation! > > (from the server's point of view) > > I may well be confused, but: a handshake is a renegotiation if-and-only-if > it is encrypted. Initial handshakes are in the clear. So there is no > ambiguity, from either party's point of view, about whether a handshake > is a renegotiation. That's not true if you're under attack. Remember that the attacker is proxying the client's messages over its own encrypted channel. -Ekr From ekr@networkresonance.com Tue Nov 10 06:49:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2997828C1EA for ; Tue, 10 Nov 2009 06:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9TNCwTrQ3El for ; Tue, 10 Nov 2009 06:49:04 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 753FE28C1C2 for ; Tue, 10 Nov 2009 06:49:04 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 7E34F69E83E; Tue, 10 Nov 2009 06:50:17 -0800 (PST) Date: Tue, 10 Nov 2009 06:50:17 -0800 From: Eric Rescorla To: David-Sarah Hopwood In-Reply-To: <4AF90946.3020104@jacaranda.org> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF90198.6010505@pobox.com> <4AF90946.3020104@jacaranda.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091110145017.7E34F69E83E@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:49:05 -0000 At Tue, 10 Nov 2009 06:33:42 +0000, David-Sarah Hopwood wrote: > > [1.1 ] > Michael D'Errico wrote: > >>> The problem is that your initial handshake *is* the renegotiation! > >>> (from the server's point of view) > >> > >> I may well be confused, but: a handshake is a renegotiation > >> if-and-only-if it is encrypted. Initial handshakes are in the clear. > >> So there is no ambiguity, from either party's point of view, about > >> whether a handshake is a renegotiation. > > > > Your initial handshake is in the clear from you to the MITM, but it gets > > sent over the already-secure connection from the MITM to the server, so > > from the server's perspective you are renegotiating. This is why you > > have to send the Renegotiation_Info extension -- it let's the server > > know that *you* think you are performing an initial handshake. It can > > then shut down the connection and save you from the attack. > > If from the server's perspective you are renegotiating, and it doesn't see > a non-empty and correct Renegotiation_Info, then it should shut down the > connection anyway. The server doesn't need to know whether the client > supports the extension; to avoid the attack, it has to shut down the > connection whether the client supports the extension or not. Yes, that's correct. -Ekr From Yair.Elharrar@audiocodes.com Tue Nov 10 07:12:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AE728C194 for ; Tue, 10 Nov 2009 07:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhcHoBdDXKBq for ; Tue, 10 Nov 2009 07:12:36 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id D745428C1C8 for ; Tue, 10 Nov 2009 07:12:33 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.1.65]) by incoming.audiocodes.com with ESMTP; 10 Nov 2009 16:49:44 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80::d9:1fca:eaba:8828]) by aclcas02.corp.audiocodes.com ([::1]) with mapi; Tue, 10 Nov 2009 17:13:33 +0200 From: Yair Elharrar To: Zheng Kanghong , "tls@ietf.org" Date: Tue, 10 Nov 2009 17:13:25 +0200 Thread-Topic: [TLS] TLS Renegotiation - Any implications to EAP-TLS ? Thread-Index: AcpiFARu5yS9rC5ZT2aJ8QIm9sUb7wAA37oQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE2A65CAAFE55048BA6682475F9A7DBF5EA6E59E82ACLMAIL01corp_" MIME-Version: 1.0 Subject: Re: [TLS] TLS Renegotiation - Any implications to EAP-TLS ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 15:12:37 -0000 --_000_CE2A65CAAFE55048BA6682475F9A7DBF5EA6E59E82ACLMAIL01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right. EAP-TLS wouldn't be vulnerable to this attack. PEAP might be vulnerable (theoretically), but the attacker would gain nothi= ng by injecting data before the tunnelled EAP. From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Zheng= Kanghong Sent: Tuesday, November 10, 2009 08:52 To: tls@ietf.org Subject: [TLS] TLS Renegotiation - Any implications to EAP-TLS ? Hi all, Anyone discussed the implications of the TLS renegotiation vulnerability to= EAP-TLS? >From my little understanding, it seems like EAP-TLS is not vulnerable. * There is no application layer protocol involved when EAP-TLS is execut= ed [Please correct me if I'm wrong]. * If client certificate authentication is required (it should), the serv= er will always request for client certificates. * After a successful EAP-TLS exchange, the TLS tunnel is not used; only = the keying material is exported [Although the tunnel is not used, is it sti= ll present and can be used in some way? Or is there no state information st= ored for the EAP method after a successful EAP exchange?). * EAP re-authentication is a new EAP exchange which is independent of th= e previous exchange. It is not the same as TLS renegotiation which is execu= ted in the previous TLS tunnel. Any comments? Thanks. - kh ________________________________ This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message --_000_CE2A65CAAFE55048BA6682475F9A7DBF5EA6E59E82ACLMAIL01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Right. EAP-TLS wouldn't be vulnerable to this attack.

PEAP might be vulnerable (theoretically), but the attacker w= ould gain nothing by injecting data before the tunnelled EAP.

 

 

From: tls-boun= ces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Zheng Kanghong
Sent: Tuesday, November 10, 2009 08:52
To: tls@ietf.org
Subject: [TLS] TLS Renegotiation - Any implications to EAP-TLS ?

 

Hi all,

Anyone discussed the implications of the TLS renegotiation vulnerability to= EAP-TLS?

>From my little understanding, it seems like EAP-TLS is not vulnerable.=

  • There is no application layer protocol involved when EAP-TLS i= s executed [Please correct me if I'm wrong].
  • If client certificate authentication is required (it should), = the server will always request for client certificates.
  • After a successful EAP-TLS exchange, the TLS tunnel is not use= d; only the keying material is exported [Although the tunnel is not used, i= s it still present and can be used in some way? Or is there no state information stored for the EAP method after a successful EA= P exchange?).
  • EAP re-authentication is a new EAP exchange which is independe= nt of the previous exchange. It is not the same as TLS renegotiation which = is executed in the previous TLS tunnel.


Any comments? Thanks.
- kh


This email and any files tra= nsmitted with it are confidential material. They are intended solely for th= e use of the designated individual or entity to whom they are addressed. If= the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, d= istribution or copying of this communication is strictly prohibited and may= be unlawful.

If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message
 --_000_CE2A65CAAFE55048BA6682475F9A7DBF5EA6E59E82ACLMAIL01corp_-- From Nicolas.Williams@sun.com Tue Nov 10 09:04:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015A23A69C0 for ; Tue, 10 Nov 2009 09:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 zMeJbSTIoktY for ; Tue, 10 Nov 2009 09:04:48 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 81D283A698D for ; Tue, 10 Nov 2009 09:04:47 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAAH5D7k015700 for ; Tue, 10 Nov 2009 17:05:14 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 nAAH5DN7056810 for ; Tue, 10 Nov 2009 10:05:13 -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 nAAGkAqY012381; Tue, 10 Nov 2009 10:46:10 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAGk9i2012380; Tue, 10 Nov 2009 10:46:09 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 10 Nov 2009 10:46:09 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091110164609.GS1105@Sun.COM> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> <4AF8E755.5020208@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF8E755.5020208@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 17:04:49 -0000 On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote: > Nicolas Williams wrote: > > On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote: > >> I whish there was a constraint that an identity/certificate that has > >> been established for a party during the TLS handshake MUST not change > >> during re-negotiation, > > Hmm, few questions about that plan: > > Is this currently a defined concept in TLS: equivalence of identity? TLS connections are not so long lived that we should worry about issues such as, for example, public key rollover or certificate expiration during a connection's lifetime. Therefore a simple Certificate octet- for-octet comparison will do for identity comparison. Anything more complicated than that (and anon->non-anon) would make Martin's proposal too unqieldy to consider at this point, and possibly ever. > Isn't that one of the major uses of renegotiation? To change identity? But only from anonymous to non-anonymous, right? That's also easy to specify. > Perhaps you want to allow identities to be "strengthened" but not > "weakened". Is this another new concept in TLS: are identities required > to be partially- or fully-ordered? > > It's starting to sound like that question about ciphersuites being > ordered according to strength. No, I don't think so. Ordering cipher suites by strength is a complex topic that I'd rather avoid for the specific enhancement that Martin proposes. > Would that make it illegal to resume a previous session over the same > underlying connection if it could not be proven it was "the same" identity? There's no authentication during session resumption handshakes -- there's only proving that both peers remember the relevant state, including master secret. > What if the session's identity were strengthened? Could you end up in a > situation where a session could be resumed on any of several other > connections except the one on which it originated! I'm not sure I follow. See above. Nico -- From mike-list@pobox.com Tue Nov 10 09:06:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6F03A683A for ; Tue, 10 Nov 2009 09:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 TLANTd7QPSZd for ; Tue, 10 Nov 2009 09:06:43 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id E7C403A69C0 for ; Tue, 10 Nov 2009 09:06:42 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E2D587BB89 for ; Tue, 10 Nov 2009 12:07:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=iGQLbmHpu6bl wflvyL+VIHI0Aps=; b=PAJVXtAHgzmrPFI7/ttO+jmgVXTqqccwjjRzKTuTxofd GnJUbEyidyV8DGs2kXib7ip//ZkNE7zHqYItWYz5Qc1lp5gVEcb0G9x2sPDkmWLx J/NbXrd0Z7fGaM9KPQ30113steoTQeFXbR37i7v2VmcNt24JPUsCooti+ZFUuWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=PmvPlu vUVa40hjeOyX2jqjVGAAKWqPZ/rp9gQbdPjwJyN9Jom+tmNW1fOHNxgU2imSYWVY wobpul8hlp+VPGEQpz9W10pDIDBDK981+uvXG7bwtwBSEeUOvk3mCX1ipmWgM/mX 9+8kNaWeulY+wQnoRtPt8bOoSirYUvvshV5oM= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DF8FB7BB87 for ; Tue, 10 Nov 2009 12:07:09 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 5A06C7BB85 for ; Tue, 10 Nov 2009 12:07:09 -0500 (EST) Message-ID: <4AF99E04.3060604@pobox.com> Date: Tue, 10 Nov 2009 09:08:20 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> In-Reply-To: <4AF9070E.4050305@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 7B7BBC46-CE1B-11DE-9E9C-7B3EEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 17:06:44 -0000 A client that wants protection from this attack MUST send the extension in its initial handshake. Why don't you want to do that? The attack being discussed happens on the client's *initial* handshake. The server sees it as a renegotiation, so the client needs to be able to tell the server that it thinks it is performing an initial handshake. That is exactly what this extension provides. If you don't send the extension on an initial handshake you are risking being attacked. All servers SHOULD disable renegotiation to protect clients, but it's been said that this is impractical. A server may be configured to allow renegotiation even though it understands the new extension. Thus by not sending the extension in your initial handshake, you are just as vulnerable, even though you could have prevented an attack. And it is actually secure for a client to renegotiate even if the server does not support the Renegotiation_Info extension. If the client has verified the server's certificate in the initial handshake, there is no MITM. Mike David-Sarah Hopwood wrote: > David-Sarah Hopwood wrote: >> Michael D'Errico wrote: >>>> Suppose that the client sent an SSLv3 ClientHello >>>> with client_version = 3.1 (or higher). Assuming the server supports TLS, >>>> then TLS will be negotiated. So when the client sends the renegotiation, >>>> it knows that it is safe to send extensions. The attack is prevented as >>>> long as the renegotiating handshake uses the extension; it is not >>>> necessary for the initial handshake to have used it. >>> The problem is that your initial handshake *is* the renegotiation! >>> (from the server's point of view) >> I may well be confused, but: a handshake is a renegotiation if-and-only-if >> it is encrypted. Initial handshakes are in the clear. So there is no >> ambiguity, from either party's point of view, about whether a handshake >> is a renegotiation. > > Actually this is not quite right, although not in a way that affects my > main point. > > A handshake is a renegotiation from the server's point of view > if-and-only-if a ciphersuite other than TLS_NULL_WITH_NULL_NULL is > in effect. It is possible that an initial handshake by a client that > was sent in the clear, could be encrypted by an attacker and appear to > the server as a renegotiation. In that case, the server can reject the > renegotiation if the ClientHello doesn't contain a correct (and non-empty) > Renegotiation_Info. > > It is also possible that, if a client that does not support the extension > requests a renegotiation on a session with the attacker, then the attacker > can decrypt it and present it to the server as an initial handshake. > But this only applies to clients that do not support the extension at all. > If a client does support it and sends it only when renegotiating, then > this variant of the attack is still prevented. > > So, I was right in my original statement that "the attack is prevented > as long as the renegotiating handshake uses the extension." Note that > both clients and servers must avoid renegotiating without using the > extension; it isn't sufficient for only servers to avoid doing so. > As long as that is the case, for a client does support the extension, > failing to send the zero-length Renegotiation_Info in an initial handshake > does not enable an attack. From marsh@extendedsubset.com Tue Nov 10 10:01:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C413A6B5B for ; Tue, 10 Nov 2009 10:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 lMIIK9FZIk3Z for ; Tue, 10 Nov 2009 10:01:45 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id DAFA53A6B5C for ; Tue, 10 Nov 2009 10:01:45 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7v2i-000C0h-Nk; Tue, 10 Nov 2009 18:02:12 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D91CD6678; Tue, 10 Nov 2009 18:02:10 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+mCnn7FQbhfC4N59CRxTbaAuHR4zRu/+o= Message-ID: <4AF9AA9E.8030603@extendedsubset.com> Date: Tue, 10 Nov 2009 12:02:06 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> <4AF8E755.5020208@extendedsubset.com> <20091110164609.GS1105@Sun.COM> In-Reply-To: <20091110164609.GS1105@Sun.COM> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 18:01:46 -0000 Nicolas Williams wrote: > On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote: > > TLS connections are not so long lived But there is no defined upper limit. > that we should worry about issues > such as, for example, public key rollover or certificate expiration > during a connection's lifetime. I agree, but we should probably check that it's documented somewhere. > Therefore a simple Certificate octet- > for-octet comparison will do for identity comparison. Anything more > complicated than that (and anon->non-anon) would make Martin's proposal > too unqieldy to consider at this point, and possibly ever. So this restriction would not apply when another auth type is used? >> Isn't that one of the major uses of renegotiation? To change identity? > > But only from anonymous to non-anonymous, right? That's also easy to > specify. One subtlety is that apps (https servers) are still expecting the transition to preserve some guarantees about identity. Even though the first session is "anonymous" it still has an identity, namely it has to be the same party as all previous non-anonymous sessions on the same connection. The proposed Renegotiation Indication extension attempts to enforce those guarantees, but I'm not sure it's so easy to specify that it shouldn't be given a lot of thought. (Consider what happens when you add various combinations of resumption into the mix.) > Ordering cipher suites by strength is a complex > topic that I'd rather avoid for the specific enhancement that Martin > proposes. Perhaps ordering levels of authentication is equally complex. >> Would that make it illegal to resume a previous session over the same >> underlying connection if it could not be proven it was "the same" identity? > > There's no authentication during session resumption handshakes -- > there's only proving that both peers remember the relevant state, > including master secret. Isn't proving "I'm the same as that other guy" a form of authentication? Surely this will be allowed: |--- session A anon ---||-- resumed A --| Is this allowed? |--- session A anon ---| |--- session B anon ---||-- resumed A --| I have heard that browsers may do this. >> What if the session's identity were strengthened? Could you end up in a >> situation where a session could be resumed on any of several other >> connections except the one on which it originated! > > I'm not sure I follow. See above. 1 |--- session A anon ---||-- session B client cert auth --| 2 |--- session C anon -----| 3 |--- session D anon -----------| 4 |--- session E anon -----| Would an effect of the proposal be that session A can be resumed on connections (2, 3, 4) but not 1? - Marsh From Nicolas.Williams@sun.com Tue Nov 10 10:34:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB4E3A6918 for ; Tue, 10 Nov 2009 10:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.024, 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 5tENq-PhUHaW for ; Tue, 10 Nov 2009 10:34:22 -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 AE8603A68EE for ; Tue, 10 Nov 2009 10:34:22 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAAIYlkx009299 for ; Tue, 10 Nov 2009 18:34:48 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 nAAIYlRf064705 for ; Tue, 10 Nov 2009 11:34:47 -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 nAAIFjCA012571; Tue, 10 Nov 2009 12:15:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAIFjr9012570; Tue, 10 Nov 2009 12:15:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 10 Nov 2009 12:15:45 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091110181544.GW1105@Sun.COM> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> <4AF8E755.5020208@extendedsubset.com> <20091110164609.GS1105@Sun.COM> <4AF9AA9E.8030603@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF9AA9E.8030603@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 18:34:23 -0000 On Tue, Nov 10, 2009 at 12:02:06PM -0600, Marsh Ray wrote: > Nicolas Williams wrote: > > On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote: > > > > TLS connections are not so long lived > > But there is no defined upper limit. True, and indeed, IMAP depends on that. Are there IMAP/other servers the request re-negotiation when a client's cert reaches/nears expiration? If so then my assertion that we don't have to worry about key rollover/ cert expiration would be wrong. Indeed, it's safer to assume that that assertion was wrong as finding out for sure would be hard. However, this is a constraint that _applications_ could enforce, or request be enforced by the TLS implementation (oh dear, back to APIs). > > that we should worry about issues > > such as, for example, public key rollover or certificate expiration > > during a connection's lifetime. > > I agree, but we should probably check that it's documented somewhere. It probably isn't. > > Therefore a simple Certificate octet- > > for-octet comparison will do for identity comparison. Anything more > > complicated than that (and anon->non-anon) would make Martin's proposal > > too unqieldy to consider at this point, and possibly ever. > > So this restriction would not apply when another auth type is used? I suppose non-anon->anon re-negotiation, but with the new inner->outer connection binding should be OK once too (to allow for re-keying without having to bother with authentication). Yes, I see your point: this is now getting too complex. Applications can always enforce that identities don't change around re-negotiation, by asking the TLS implementation what the IDs were before and after re-negotiation, and by sticking to simple rules (e.g., cert octet-wise comparison) even if those defeat key/cert rollover. But if we're going to let apps do ths (and I think now only apps should) then there's no place in EKR's I-D for text about it, except, maybe, in the Security Considerations section (since TLS defines no APIs). > One subtlety is that apps (https servers) are still expecting the > transition to preserve some guarantees about identity. Even though the > first session is "anonymous" it still has an identity, namely it has to > be the same party as all previous non-anonymous sessions on the same > connection. > > The proposed Renegotiation Indication extension attempts to enforce > those guarantees, but I'm not sure it's so easy to specify that it > shouldn't be given a lot of thought. (Consider what happens when you add > various combinations of resumption into the mix.) Certainly channel binding is _always_ easier than identity equivalence. That's the main reason I have been pushing channel binding. There are a number of protocols where the only way to ensure there's no MITM is to ensure that one sees the same server identity on the server end of two channels -- that's asking for trouble. > > Ordering cipher suites by strength is a complex > > topic that I'd rather avoid for the specific enhancement that Martin > > proposes. > > Perhaps ordering levels of authentication is equally complex. If you're willing to make certain simplifying assumptions (e.g., no need for key/cert rollover), then authenticated ID equivalence can be simple. If you're not willing to make those assumptions then yes, it becomes as complex as cipher suite strength ordering. > Isn't proving "I'm the same as that other guy" a form of authentication? I.e., channel binding. It doesn't authenticate identities, but it does "authenticate" that two end-points are logically the same entity. > Surely this will be allowed: > > |--- session A anon ---||-- resumed A --| > > Is this allowed? I.e., negotiate an anonymous session, then re-negotiate where the re-negotiation is just a resumption of the anon session? Ick. > |--- session A anon ---| > |--- session B anon ---||-- resumed A --| > > I have heard that browsers may do this. I think session resumption in a re-negotiation should probably be out, yes. Nico -- From dispensa@phonefactor.com Tue Nov 10 11:21:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F163A6983 for ; Tue, 10 Nov 2009 11:21:21 -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 Vad16w4hLwAY for ; Tue, 10 Nov 2009 11:21:20 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 5B1A53A684A for ; Tue, 10 Nov 2009 11:21:20 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKSvm9S/YKnU0H8d9q1mdE5EPrW0A26zSG@postini.com; Tue, 10 Nov 2009 11:21:48 PST Received: from 10.10.9.106 ([10.10.9.106]) by pos-exch1.corp.positivenetworks.net ([204.13.120.8]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 Nov 2009 19:19:55 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 10 Nov 2009 13:21:46 -0600 From: Steve Dispensa To: Nicolas Williams , Marsh Ray Message-ID: Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: AcpiOwr2wV5krGuUk0S+Ovc7Bvw9YQ== In-Reply-To: <20091110181544.GW1105@Sun.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 19:21:21 -0000 On 11/10/09 12:15 PM, "Nicolas Williams" wrote: > On Tue, Nov 10, 2009 at 12:02:06PM -0600, Marsh Ray wrote: >> Nicolas Williams wrote: >>> On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote: >>> >>> TLS connections are not so long lived >> >> But there is no defined upper limit. > > True, and indeed, IMAP depends on that. Are there IMAP/other servers > the request re-negotiation when a client's cert reaches/nears > expiration? Has anyone considered SSL VPN's and/or things like GoToMyPC? > If so then my assertion that we don't have to worry about key rollover/ > cert expiration would be wrong. Indeed, it's safer to assume that that > assertion was wrong as finding out for sure would be hard. OTOH, we could require that app-level protocols support re-establishment of the underlying TLS session once crypto state gets stale (in the opinion of either client or server). -Steve From mrex@sap.com Tue Nov 10 11:27:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735B83A67EA for ; Tue, 10 Nov 2009 11:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 TKFdy51DPj1S for ; Tue, 10 Nov 2009 11:27:52 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0728D28C0DF for ; Tue, 10 Nov 2009 11:27:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAAJSHjR005722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 20:28:17 +0100 (MET) From: Martin Rex Message-Id: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Tue, 10 Nov 2009 20:28:16 +0100 (MET) In-Reply-To: <4AF99E04.3060604@pobox.com> from "Michael D'Errico" at Nov 10, 9 09:08:20 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 19:27:53 -0000 Michael D'Errico wrote: > > A client that wants protection from this attack MUST send the extension > in its initial handshake. Why don't you want to do that? If there were only well-behaved servers out there, there would not be any problem. The default configuration of MSIE6 on WinXP to disable TLSv1.0, as well as newer browsers providing a reconnect fallback to SSLv3-only ClientHello indicate that there is an installed base of TLS servers that either predates the SSLv3 internet-draft from Nov,18th 1996 or is defective. There used to be a draft draft-pettersen-tls-interop-experience-xx.txt (I have archived a -00 that expired oct-2006), which describes the mess around spec non-compliance. TLS-extensions are covered in section 4. What it seems to indicate, in essence, is that the for maximum interoperability with the installed base of (broken) servers out there, you use a SSLv3 ClientHello with (0x03,0x00) in the client.version and _no_ TLS extensions. So conservative clients that do not want to implement reconnect fallbacks may have a problem with the recommendation to always use a TLS extension. There are a number of things we would like to achieve with a fix: - provide a method for secure renegotiation in the future - deprecate the traditional renegotiation - provide a secure base for the (previously flawed) assumptions of servers when performing a renegotiation to request a client certificate. in oder to achieve this, we should probably make the following recommendations: - if a TLS client (any protocol version, including SSLv3) performs renegotiation (i.e. sends a ClientHello over an established TLS session with a ciphersuite other than TLS_NULL_WITH_NULL_NULL), then it SHOULD always and unconditionally use the TLS extension Renegotiation_Info containing the verify_data of the client.finished handshake message from the active TLS session, The TLS client should do that even when it did not send the TLS extension Renegotiation_Info with and empty extension data in the initial TLS handshake on a connection! Lacking application level re-connect provisions for forward-incompatible SSL/TLS servers, a TLS client might not want to sent the TLS extension in the initial ClientHello of a connection. If the presence of the TLS extension Renegotiation_Info causes the server to abort the TLS connection, then that server is not capable of secure renegotiation, and the TLS client should abort the Handshake with an error and close the connection in order to protect the client and the clients credential from abuse with servers that are still vulnerable to the TLS renegotiation problem. - A TLS server (any protocol version, including SSLv3) should require the presence of a TLS extension Renegotiation_Info for _every_ renegotiation handshake. If the TLS extension Renegotiation_Info is absent from the ClientHello received on an active TLS session, the server should abort the connection. (add Alert here) If the TLS extension Renegotiation_Info is present, then the TLS server MUST verify the contained verify_data of the client.finished message as known to the client with its own memorized client.finished message from the SecurityParameters of the current TLS connection state. If the comparison of the verify_data from the client.finished messages fails, the server MUST abort the connection. When the client's and the server's notion of the verify_data from the previous TLS session compare equal, the server MUST send back the TLS extension RenegotiationInfo with in a ServerHelloExtension containing the verify_data from the client.finished message and the verify_data from the server.finished message. - A TLS client (any protocol version, including SSLv3) that receives the TLS extension Renegotiation_Info in a ServerHello extension must compare the extension data with its own SecurityParameters in the TLS connection state. If the Renegotiation_Info with empty extension_data is received on a client's initial TLS handshake, everything is fine If the Renegotiation_Info with empty extension_data is received on an active TLS session, the client MUST abort the handshake with an error and close the connection. If the Renegotiation_Info with non-empty extension_data is received on a client's initial TLS handshake, the client MUST abort the handshake with an error and close the connection. If the Renegotiation_Info with non-empty extension_data is received on a client's renegotiation handshake, the client MUST compare the contained verify_data of the server-memorized client.finished and server.finished messages with its own memorized verify_data for both finished messages in the SecurityParameters of the TLS connection state for the current session. - if they compare equal, everything is fine - if they do not match, the client MUST abort the handshake and close the connection. It is possible that a TLS client may not want to assert the TLS extension Renegotiation_Info in an initial ClientHello because of interoperability concerns with an installed base of not-quite-spec-compliant servers. What other strategies could be used on the initial handshake on a connection with lesser side effects that a TLS extension Renegotiation_Info with empty extension_data? Overloading ("abusing") the semantics of other regular elements of an SSL/TLS handshake that have a lesser likelihood to upset legacy servers. - Assign one (or two) specific ciphersuite IDs that the client can include in the ciphersuites list which signal the clients notion of the connection state (initial vs. renegotiation) to the server. - Assign one (or two) compression algorithm IDs that the client can include in the supported compression algorithms list which signal the clients notion of the connection state (initial vs. renegotiation) to the server. I assume that a Client->Server signalling through a special cipher suite might be the easy to implement for clients and expect that it has the least side effects on handshakes with old servers. Fancy compression algs might be less digestable to old servers. Both of these (one or two fany ciphersuites in the ciphersuite list of the client) can only be used for signalling from client to server, not in the direction server to client. What could be used to signal from the server to the client that the client should send the TLS extension Renegotiation_Info in the ClientHello of a renegotiation handshake if the client does not want to send the TLS extension in the initial handshake of a connection? We could define a new TLS handshake message "RenegotiationRequest" to be sent instead of a "HelloRequest". This would be an option for those servers, that will abort the handshake and connection if the client does not send the TLS extension Renegotiation_Info. The purpose of a RenegotiationRequest would be to encourage clients to send the TLS extension Renegotiation_Info, in order to keep existing usage scenarios usable. The message itself is not protected, but that doesn't matter. The servers decision for success or failure of the renegotiation depends only and entirely on the use of the TLS extension Renegotiation_Info in the renegotiation handshake and successful verification of the verify_data from the client.finished handshake message of the active TLS session. -Martin From dispensa@phonefactor.com Tue Nov 10 11:37:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D6328C15A for ; Tue, 10 Nov 2009 11:37:04 -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 fgRdqEBSOfoI for ; Tue, 10 Nov 2009 11:37:03 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id C67CC3A67EA for ; Tue, 10 Nov 2009 11:37:02 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKSvnA+QeQe1qD2N4otEOXBvwczd8JgsAj@postini.com; Tue, 10 Nov 2009 11:37:30 PST Received: from 10.10.9.106 ([10.10.9.106]) by pos-exch1.corp.positivenetworks.net ([204.13.120.8]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 Nov 2009 19:35:37 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 10 Nov 2009 13:37:27 -0600 From: Steve Dispensa To: , Michael D'Errico Message-ID: Thread-Topic: [TLS] TLSrenego - current summary of semantics and possibilities Thread-Index: AcpiPTvXuQF4GNyNjEOph1qMO6f3fA== In-Reply-To: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 19:37:04 -0000 On 11/10/09 1:28 PM, "Martin Rex" wrote: > - if a TLS client (any protocol version, including SSLv3) performs > renegotiation (i.e. sends a ClientHello over an established > TLS session with a ciphersuite other than TLS_NULL_WITH_NULL_NULL), > then it SHOULD always and unconditionally use the TLS extension > Renegotiation_Info containing the verify_data of the client.finished > handshake message from the active TLS session, > The TLS client should do that even when it did not send the > TLS extension Renegotiation_Info with and empty extension data > in the initial TLS handshake on a connection! > > Lacking application level re-connect provisions for forward-incompatible > SSL/TLS servers, a TLS client might not want to sent the TLS extension > in the initial ClientHello of a connection. This was discussed a bit at the Sept. 29 meeting. I had originally suggested that the extension need not be present during initial negotiations at all, but it was pointed out that network management systems might want to inventory patched clients and servers. > Overloading ("abusing") the semantics of other regular elements > of an SSL/TLS handshake that have a lesser likelihood to upset > legacy servers. This is an interesting potential solution to the network monitoring problem, if nothing else. -Steve From mrex@sap.com Tue Nov 10 12:11:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F6B3A6928 for ; Tue, 10 Nov 2009 12:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 I84HEEa6sCVQ for ; Tue, 10 Nov 2009 12:11:44 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 17DE43A68FC for ; Tue, 10 Nov 2009 12:11:43 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAAKC7ef001106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 21:12:07 +0100 (MET) From: Martin Rex Message-Id: <200911102012.nAAKC5HV022217@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 10 Nov 2009 21:12:05 +0100 (MET) In-Reply-To: <20091110181544.GW1105@Sun.COM> from "Nicolas Williams" at Nov 10, 9 12:15:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:11:45 -0000 Nicolas Williams wrote: > > Marsh Ray wrote: > > > > Nicolas Williams wrote: > > > > > > TLS connections are not so long lived > > > > But there is no defined upper limit. > > True, and indeed, IMAP depends on that. Are there IMAP/other servers > the request re-negotiation when a client's cert reaches/nears > expiration? There is only a suggestion in the TLS spec that a TLS session ID should not be valid for more than 24 hours. That refers to the TLS session cache and the possibility to resume a TLS session, not for the lifetime of an established TLS session. Busy Web-Servers may use significantly shorter session cache lifetimes (our default is 15 minutes). TLS connection lifetimes and session lifetimes, in particular for SSL-VPNs that Steve mentioned, might be much longer. But keep in mind, that issuer of credentials (like CAs) may have a problem if an authenticated session can be held for several days even though the credential may have long be expired, revoked or the ACL may have been updated in the interim. An application that depends on an authentication to be valid for several days or weeks is probably a security problem all by itself. How about recommending two recommendations instead of one: - TLS implementations should, by default, lock down identities during session renegotiation once they have been established in a TLS handshake, i.e. the implementation should ensure they match exactly (e.g. memcmp() of the certificate blob). Identities not previously established in a TLS handshake can be established in a renegotiation for the first time. - TLS implementations are encouraged to offer an API to the applications where an application can request permission for a change in identities during renegotiation. Application protocols that need this functionality, MUST specify the procedure how to perform authentication of the peer and the semantics of a change in identity during renegotiation. TLS implementations must provide a signaling facility to such applications to distinguish application data received over the original TLS session from application data received over the newly renegotiated TLS session. > > I suppose non-anon->anon re-negotiation, but with the new inner->outer > connection binding should be OK once too (to allow for re-keying without > having to bother with authentication). I do not like that idea. If renegotiation is performed and the identity is maintained, this can be detected with a memcmp() on the certificate blob, and then one can skip that authentication. If the identity changes, a re-authentication ought to be performed. Usually the issuer of a certificate assumes that it can no longer be used once it is expired, but if you allow renegotiations to Renegotiation creates a new session, that servers will usually add to their session caches. If such a session is resumed from the cache on a new connection, you can _not_ perform an authentication. -Martin From djhopwood@googlemail.com Tue Nov 10 12:16:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF49D3A68E4 for ; Tue, 10 Nov 2009 12:16:16 -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 ux8n1mDC18o3 for ; Tue, 10 Nov 2009 12:16:16 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id C58053A68E7 for ; Tue, 10 Nov 2009 12:16:15 -0800 (PST) Received: by ewy3 with SMTP id 3so436269ewy.37 for ; Tue, 10 Nov 2009 12:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=ra+lXm26g50XMUD6839YbQTZRwcbBq+x6DSzDgXrzqQ=; b=l3yhZoteK5wJ5P9/Z5ATXuGj6cAml27z9G+L0ZAIxCAOQ/F4OkVQwA8U01HDAlsd8+ CQ1n1tn6Seb9cyPA1fKEM/2kBkC8nzyUy8vW3YT/cCbURullHR4uDRYLVtAwDCGRsNK0 CwFtx7OHfXwDSxSf53+hshAp0mX5VrhC3eL+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=V4mxWFbOJ8UGY12n9xJ1HgfjhFCFr9K+0a6uacHl1cLRLxgPkciJXETjnajKymm/IS xiWVWUqXWtQnCa+kOLs1B3pfoIlPO/mheERs9Px737mqTcGiCcoxBA81iFMYXxurpwlm Ob9PVfYCoGnL3WRks5IA7Pd87Skz6hNOTMJW8= Received: by 10.213.0.152 with SMTP id 24mr610512ebb.61.1257884197413; Tue, 10 Nov 2009 12:16:37 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 28sm2490454eyg.46.2009.11.10.12.16.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 12:16:36 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AF9CA1B.7050407@jacaranda.org> Date: Tue, 10 Nov 2009 20:16:27 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> <4AF8E755.5020208@extendedsubset.com> <20091110164609.GS1105@Sun.COM> <4AF9AA9E.8030603@extendedsubset.com> In-Reply-To: <4AF9AA9E.8030603@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig54E267F9D4BFFCFBCB21375F" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:16:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig54E267F9D4BFFCFBCB21375F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > Is this allowed? >=20 > |--- session A anon ---| > |--- session B anon ---||-- resumed A --| >=20 > I have heard that browsers may do this. Ouch -- I thought that I understood the attack, and now you've just given= me another headache ;-) Do servers support a renegotiation that resumes a different session? That seems like a really bad idea. Since a resumption may always be refused, clients can't be relying on this behaviour. So we could compatibly specify that servers MUST NOT accept such a resumption. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig54E267F9D4BFFCFBCB21375F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr5yiMACgkQWUc8YzyzqAe7vAD9FBDaOapMnLYWT0gw5FhtfWlV 7yrlwOoEAuDuqkwjE2wA/RP5NlrUFohAM/QSJHmS5b6bKrd/iIv3xOkttFiKA0fp =TqUk -----END PGP SIGNATURE----- --------------enig54E267F9D4BFFCFBCB21375F-- From mrex@sap.com Tue Nov 10 12:34:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2F63A68E7 for ; Tue, 10 Nov 2009 12:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 6BGVuJEuGhI4 for ; Tue, 10 Nov 2009 12:34:46 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C830C3A67E4 for ; Tue, 10 Nov 2009 12:34:21 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAAKYkvZ027150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 21:34:46 +0100 (MET) From: Martin Rex Message-Id: <200911102034.nAAKYjkA023781@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Tue, 10 Nov 2009 21:34:45 +0100 (MET) In-Reply-To: <4AF8E755.5020208@extendedsubset.com> from "Marsh Ray" at Nov 9, 9 10:08:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:34:47 -0000 Marsh Ray wrote: > > Nicolas Williams wrote: > > On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote: > >> I whish there was a constraint that an identity/certificate that has > >> been established for a party during the TLS handshake MUST not change > >> during re-negotiation, > > Hmm, few questions about that plan: > > Is this currently a defined concept in TLS: equivalence of identity? blob_compare(current-cert-blob,new-cert-blob) Everything more complicated should be an apps issue--provided that the apps has provided "convincing arguments" to the TLS implementation (i.e. correctly instrumented the relevant APIs) that it is competent to perform such a re-authentication as a result of an identity change during renegotiation. > > Isn't that one of the major uses of renegotiation? To change identity? I simply don't know. Our server doesn't support renegotiation. And I learned our client to do it several years ago since it was used in certain configurations of MS IIS to ask for a client certificate after having seen the request. > > That seems to be the entire point of the observed cases of renegotiation > in https. Even if the only case we know of is a transition from an > anonymous identity to a client-certified one, such a new constraint > seems a bit pointless and likely to break someone. This might not accurately describe the situation you have in mind. A client that has not sent a certificate (usually because the server didn't send a CertificateRequest) is definitely not an "established anonymous identity". It is simply the absence of an identity. The use of a DH_anon ciphersuite, on the other hand, might be considered to establish an anonymous identity for the server. I do not like the DH_anon ciphersuites and I'm wondering what TLS implementations do that provide applications a callback for verification of the server cert which is usually called while processing the ServerCertificate handshake message when the server selects a DH_anon ciphersuite (in which case there is no ServerCertificate handshake message). -Martin From Nicolas.Williams@sun.com Tue Nov 10 12:43:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E47D3A68E7 for ; Tue, 10 Nov 2009 12:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.018, 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 o42csXrXM9Pi for ; Tue, 10 Nov 2009 12:43:54 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 8F6953A68AF for ; Tue, 10 Nov 2009 12:43:53 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAAKiKYx006953 for ; Tue, 10 Nov 2009 20:44:21 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 nAAKiKvn060866 for ; Tue, 10 Nov 2009 13:44:20 -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 nAAKWlWO012744; Tue, 10 Nov 2009 14:32:47 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAKWkTT012743; Tue, 10 Nov 2009 14:32:46 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 10 Nov 2009 14:32:46 -0600 From: Nicolas Williams To: Steve Dispensa Message-ID: <20091110203245.GB1105@Sun.COM> References: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:43:55 -0000 On Tue, Nov 10, 2009 at 01:37:27PM -0600, Steve Dispensa wrote: > On 11/10/09 1:28 PM, "Martin Rex" wrote: > > - if a TLS client (any protocol version, including SSLv3) performs > > renegotiation (i.e. sends a ClientHello over an established > > TLS session with a ciphersuite other than TLS_NULL_WITH_NULL_NULL), > > then it SHOULD always and unconditionally use the TLS extension > > Renegotiation_Info containing the verify_data of the client.finished > > handshake message from the active TLS session, > > The TLS client should do that even when it did not send the > > TLS extension Renegotiation_Info with and empty extension data > > in the initial TLS handshake on a connection! > > > > Lacking application level re-connect provisions for forward-incompatible > > SSL/TLS servers, a TLS client might not want to sent the TLS extension > > in the initial ClientHello of a connection. > > This was discussed a bit at the Sept. 29 meeting. I had originally suggested > that the extension need not be present during initial negotiations at all, > but it was pointed out that network management systems might want to > inventory patched clients and servers. I guess we'll see whether the need to interop with broken servers (which are probably broken forever, and therefore vulnerable forever) is important enough that implementors will have to include a knob for whether to send this extension on initial negotiations. I consider the fact that it will break such broken servers a feature, but one must be realistic also. Nico -- From Yair.Elharrar@audiocodes.com Tue Nov 10 12:54:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83CB3A6907 for ; Tue, 10 Nov 2009 12:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 GhbdwLHzCKkr for ; Tue, 10 Nov 2009 12:54:46 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id F3EBE3A62C1 for ; Tue, 10 Nov 2009 12:54:21 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.0.13]) by incoming.audiocodes.com with ESMTP; 10 Nov 2009 22:31:32 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80:0000:0000:0000:00d9:1fca:234.186.136.40]) by aclcas.corp.audiocodes.com ([10.1.0.13]) with mapi; Tue, 10 Nov 2009 22:55:21 +0200 From: Yair Elharrar To: Steve Dispensa Date: Tue, 10 Nov 2009 22:52:03 +0200 Thread-Topic: [TLS] TLSrenego - current summary of semantics and possibilities Thread-Index: AcpiPTvXuQF4GNyNjEOph1qMO6f3fAACmwhv Message-ID: References: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:54:47 -0000 Steve Dispensa wrote: >> >> Lacking application level re-connect provisions for forward-incompat= ible >> SSL/TLS servers, a TLS client might not want to sent the TLS extensi= on >> in the initial ClientHello of a connection. > > This was discussed a bit at the Sept. 29 meeting. I had originally sugges= ted > that the extension need not be present during initial negotiations at all= , > but it was pointed out that network management systems might want to > inventory patched clients and servers. This could backfire. It would allow hackers to detect unpatched clients, an= d focus their attacks on them. Yair -- This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message From mike-list@pobox.com Tue Nov 10 12:57:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A683D3A6A2F for ; Tue, 10 Nov 2009 12:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 K62qAMt3Ogc1 for ; Tue, 10 Nov 2009 12:57:22 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id A4F903A68C9 for ; Tue, 10 Nov 2009 12:57:22 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C0F929AF07 for ; Tue, 10 Nov 2009 15:57:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=CgAJGHUS0ycJ k7fbft3yxpVK0rE=; b=g6peYW0pKnDFCUeFChFBhfXIHGh3P6MDNhCQ6pCPYGSu wXVxQG9wzAUjWKrSGA8EPmKhFonW3NOymutb16QcecSnnPoPg3UlvHZ+1Te1ynW2 GcvrOT0LT9fc1Rd9NejW87dMset/CKZcbzlIy2WPUmAHFDnj5osdE71RNBFITc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=gwnYOU ad7SnHS713ibVXwneiPotHZnlDxq36lLKtwj3XOBEJcLgN5ZdL2ciyY33X1ZlkIe sLtOYcINXZMb6Dyp24RtQcQmZ5lRStoSPV6I7LAJc5IQ6zvSNchIelLJvC5iC8VQ KPCjR6Wehuk76Tfw9i0M2whR8o7WEm0JrUPCw= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id BE4089AF06 for ; Tue, 10 Nov 2009 15:57:48 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id D44B69AF02 for ; Tue, 10 Nov 2009 15:57:47 -0500 (EST) Message-ID: <4AF9D413.7090408@pobox.com> Date: Tue, 10 Nov 2009 12:58:59 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> In-Reply-To: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: B414D13A-CE3B-11DE-8380-BD45BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:57:23 -0000 > It is possible that a TLS client may not want to assert the TLS extension > Renegotiation_Info in an initial ClientHello because of interoperability > concerns with an installed base of not-quite-spec-compliant servers. Then it will end up buying a lot of pizza. Simply finishing the *initial* handshake completes the attack! (The server saw it as a renegotiation, not the client.) To protect against this, the only thing that a client can do is include the empty renegotiation info extension. If the server returns it and the handshake completes, there is no MITM. In fact if you were to then renegotiate, you wouldn't need the extension (!) because you are already certain that the handshake was with the server and not the MITM. There are a few possible results of sending the extension: a) the server responds with the extension b) the server responds without including the extension c) the server "crashes" because of the extension (a) is fine as long as the extension is empty. (c) could be simulated by the MITM, so be careful -- falling back to a less-secure mode can play into their hands (b) continue at your own risk -- a client could hold off on sending a certificate (if requested) and not send any Cookies. The HTTPS request will fail, but the client can just reissue it after the failure -- possibly after renegotiating to send its certificate (this is secure if the client has verified the server's cert). > Overloading ("abusing") the semantics of other regular elements > of an SSL/TLS handshake that have a lesser likelihood to upset > legacy servers. > > - Assign one (or two) specific ciphersuite IDs that the client > can include in the ciphersuites list which signal the clients > notion of the connection state (initial vs. renegotiation) > to the server. > > - Assign one (or two) compression algorithm IDs that the client > can include in the supported compression algorithms list which > signal the clients notion of the connection state (initial vs. > renegotiation) to the server. I would not like to see this kind of solution. If code has to change, Do The Right Thing. > We could define a new TLS handshake message "RenegotiationRequest" > to be sent instead of a "HelloRequest". This would be an option for > those servers, that will abort the handshake and connection > if the client does not send the TLS extension Renegotiation_Info. Again, the attack happens on the client's *initial* handshake, so it never receives a HelloRequest. Mike From mrex@sap.com Tue Nov 10 13:00:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A5B3A6900 for ; Tue, 10 Nov 2009 13:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.862 X-Spam-Level: X-Spam-Status: No, score=-5.862 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 tP2AbYozFQnt for ; Tue, 10 Nov 2009 13:00:48 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 8B59C3A68AF for ; Tue, 10 Nov 2009 13:00:45 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAAL1B54008272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 22:01:11 +0100 (MET) From: Martin Rex Message-Id: <200911102101.nAAL1Ai9025439@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Tue, 10 Nov 2009 22:01:10 +0100 (MET) In-Reply-To: <4AF8F363.2030201@pobox.com> from "Michael D'Errico" at Nov 9, 9 09:00:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:00:52 -0000 Michael D'Errico wrote: > > > As previously described in another message, the current spec has a > > requirement that additonal application data may be arbitrarily > > interleaved with a renegotiation handshake. I think this requirement > > makes a security assessment of the protocol impossible for changing > > identities. > > If your TLS API was able to tell you exactly where in the application > data stream a renegotiation has completed successfully, you would > be able to apply the original security parameters to the data received > prior to the renegotiation, and then switch to the new parameters for > the data received after the renegotiation. What about the application data sent between the ChangeCipherSpec and the Finished messages? It certainly must be encrypted by the crypto parameters of the new session. But it can not be considered authentic before the finished messages have been verified. And when the finished messages verify, then I consider it inappropriate to associate that data with the _previously_ authenticated session&identity. Since the current SSL&TLS specs are completely ambiguous, you can not claim "if your TLS API was able to tell you exactly where in the application data stream", because currently no such semantics exist! Two independent implementations of TLS that claim to tell you exactly where the position is may identify entirely different positions -- and with the current spec, it is impossible to decide where the position should be. > > That would catch the MITM attack being discussed now. We're going to plug that MITM attack with secure renegotiation. But that will not affect the miserable ambiguity for where the original session ends and the new session starts if we do allow established identities to change during renegotiation. To fix that, we will have to spell out the precise semantics in a specification. IMHO, the cleanest would be to disallow application data transfer during a renegotiation handshake. > > > Personally, I would it find much cleaner if the semantics for the > > renegotiation would require the TLS peers to suspend transmission > > of application data while performing TLS renegotiation, > > i.e. > > > > the client must not send any application data between > > ClientHello and the client's Finished message > > > > the server must not send any application data between > > ServerHello and either no_renegotiation alert or > > the server's Finished message > > > > the client must drop all application data received > > between ServerHello and either no_renegotiation alert > > or the server's Finished message > > > > the server must drop all application data received > > between the ClientHello and the client's Finished message > > When I first implemented TLS, the only reason I could envision for > renegotiation was to refresh the symmetric keys, so I made it work > asynchronously. I wrote about it in this message: > > http://www.ietf.org/mail-archive/web/tls/current/msg04042.html > > With this design, application data can flow at nearly full speed while > a renegotiation is taking place. Requiring all data to stop flowing > during a renegotiation, may be unnecessary in some situations. If you lock down established identites, then I do not see a problem with this. For a delayed TLS client-cert authentication, this implies the semantics that the newly established identity assumes responsibility for everything that has been sent over the previous session. (The assumption that is currently a problem for servers doing renegotiation without a cryptographic binding between previous and renegotiated session. > I do see however, that data probably needs to stop flowing after sending > a Finished message until receiving the peer's Finished message, but > that affects only one direction and last for one round trip, not two. Why Finished? I think its everything following the ChangeCipherSpec. > > When you add changing client credentials to the mix, then data flow > probably has to stop, but that is really an application-level decision. > Also silently dropping data never seems like the right thing to do IMHO. _I_ did not write _silent_ dropping. Dropping and aborting is fine. Dropping in the sense of "MUST NOT make it available to the application". I said "drop" after having previously specified that the other side MUST NOT send during the handshake. That MUST NOT send app data directly translates to a requirement for the receiver to drop that data. Sending an alert when that happens and closing the connection is fine with me. > > > Are there currently applications that actively abuse the possibility > > provided by the spec to interleave application data and handshake > > messages of a TLS renegotiation handshake (provided that the > > TLS implementation that (a) they're using and (b) they're talking > > to actually allow this. The fact that the spec says so, doesn't > > mean that everyone has implemented it in this fashion (since it > > is complex,difficult and possibly insecure)? > > Yes, see the above referenced message. But I don't agree that it's > abuse since that is what the spec. says to do. I certainly didn't not want to blame you for implementing exactly what the TLS spec says in your TLS implementation. I'm sorry if I wrote it that way. I'm wondering whether there are application that actively abuse this feature and would break if the TLS implementation would exhibit semantics similar to those I outlined above and fail with an error if the TLS implementation would reject application data while performing the renegotiation handshake. -Martin From stpeter@stpeter.im Tue Nov 10 13:08:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9BE3A6B30 for ; Tue, 10 Nov 2009 13:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 RrgamxHeyU0b for ; Tue, 10 Nov 2009 13:08:43 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B5DF83A6B2F for ; Tue, 10 Nov 2009 13:08:43 -0800 (PST) Received: from host-113-169.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7CF9540D09; Tue, 10 Nov 2009 14:09:10 -0700 (MST) Message-ID: <4AF9D674.6010500@stpeter.im> Date: Wed, 11 Nov 2009 06:09:08 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF03@il-ex01.ad.checkpoint.com> <200911092152.nA9LqVkW000963@fs4113.wdf.sap.corp> <20091109223417.GK1105@Sun.COM> <4AF8E755.5020208@extendedsubset.com> <20091110164609.GS1105@Sun.COM> <4AF9AA9E.8030603@extendedsubset.com> <20091110181544.GW1105@Sun.COM> In-Reply-To: <20091110181544.GW1105@Sun.COM> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:08:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/11/09 3:15 AM, Nicolas Williams wrote: > On Tue, Nov 10, 2009 at 12:02:06PM -0600, Marsh Ray wrote: >> Nicolas Williams wrote: >>> On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote: >>> >>> TLS connections are not so long lived >> But there is no defined upper limit. > > True, and indeed, IMAP depends on that. Are there IMAP/other servers > the request re-negotiation when a client's cert reaches/nears > expiration? > > If so then my assertion that we don't have to worry about key rollover/ > cert expiration would be wrong. Indeed, it's safer to assume that that > assertion was wrong as finding out for sure would be hard. > > However, this is a constraint that _applications_ could enforce, or > request be enforced by the TLS implementation (oh dear, back to APIs). IMHO this is the responsibility of the application. For example in XMPP we use long-lived TCP connections and, on top of those, long-lived XML streams that can be TLS-protected. In practice, for server-to-server federation (and even for client-to-server communication) those connections might be up for days, weeks, even months. At this point the handling of long-lived XML streams is unspecified, but I would expect most XMPP servers to terminate the connection and force the other party to reconnect. I'll bring this up on the XMPP WG list... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr51nQACgkQNL8k5A2w/vwTMgCdHDyyU/rnldyl27WEtBik6oTv eKQAoNIY18NGdVOjSpEtpsTPWV49RhQc =Rah7 -----END PGP SIGNATURE----- From marsh@extendedsubset.com Tue Nov 10 13:17:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D013A6964 for ; Tue, 10 Nov 2009 13:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 deOCRXOrRsYs for ; Tue, 10 Nov 2009 13:17:08 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id E7F2F3A68C7 for ; Tue, 10 Nov 2009 13:17:07 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7y5m-000JDa-VK; Tue, 10 Nov 2009 21:17:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0E8F26678; Tue, 10 Nov 2009 21:17:32 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+egRfDh4cdgSWTu0mI21Oob7S7dT642S8= Message-ID: <4AF9D868.1030206@extendedsubset.com> Date: Tue, 10 Nov 2009 15:17:28 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> <20091110203245.GB1105@Sun.COM> In-Reply-To: <20091110203245.GB1105@Sun.COM> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:17:08 -0000 Nicolas Williams wrote: > On Tue, Nov 10, 2009 at 01:37:27PM -0600, Steve Dispensa wrote: >> This was discussed a bit at the Sept. 29 meeting. I had originally suggested >> that the extension need not be present during initial negotiations at all, >> but it was pointed out that network management systems might want to >> inventory patched clients and servers. > > I guess we'll see whether the need to interop with broken servers (which > are probably broken forever, and therefore vulnerable forever) is > important enough that implementors will have to include a knob for > whether to send this extension on initial negotiations. I consider the > fact that it will break such broken servers a feature, but one must be > realistic also. It's one thing to say, realistically, some client applications may elect to put their users at risk for the sake of continuing to work with defective servers. It's something else entirely to propose that an IETF spec's official language and recommended practice for implementors should be weakened in consideration for these noncompliant systems. Perhaps those responsible for such systems will take this opportunity to update them? Yair Elharrar wrote: > This could backfire. It would allow hackers to detect unpatched > clients, and focus their attacks on them. There are plenty of ways for to attackers to fingerprint clients (looked at a user-agent string lately?) and it doesn't make sense to make life difficult for those who have a legitimate need for the data. Again, where there are trade-offs affecting security and interoperability, let us favor the side of implementations that will follow the specs and recommendations over those which do not. - Marsh From uri@ll.mit.edu Tue Nov 10 13:30:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3544C3A6A2A for ; Tue, 10 Nov 2009 13:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+oiInfJEpKP for ; Tue, 10 Nov 2009 13:30:42 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 9716C3A682D for ; Tue, 10 Nov 2009 13:30:42 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAALV4fh000928; Tue, 10 Nov 2009 16:31:04 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAafa4zJ; Tue Nov 10 16:20:02 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Tue, 10 Nov 2009 16:20:02 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'marsh@extendedsubset.com'" Date: Tue, 10 Nov 2009 16:19:23 -0500 Thread-Topic: [TLS] TLSrenego - current summary of semantics and possibilities Thread-Index: AcpiSysjhGpjvZMuQTGXaeJ6uZw4BgAAGTtG Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3CD@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:30:44 -0000 TWFyc2gsDQoNCkNhbm5vdCBhZ3JlZSBtb3JlLiANCg0KKEluIGZhY3QgSSdtIHN1cnByaXNlZCB0 aGF0IGl0IGhhZCB0byBiZSBzdGF0ZWQhIDotKQ0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCkZyb206IHRscy1ib3VuY2VzQGlldGYub3JnIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4N ClRvOiBOaWNvbGFzIFdpbGxpYW1zIDxOaWNvbGFzLldpbGxpYW1zQHN1bi5jb20+DQpDYzogdGxz QGlldGYub3JnIDx0bHNAaWV0Zi5vcmc+DQpTZW50OiBUdWUgTm92IDEwIDE2OjE3OjI4IDIwMDkK U3ViamVjdDogUmU6IFtUTFNdIFRMU3JlbmVnbyAtIGN1cnJlbnQgc3VtbWFyeSBvZiBzZW1hbnRp Y3MgYW5kIHBvc3NpYmlsaXRpZXMNCg0KTmljb2xhcyBXaWxsaWFtcyB3cm90ZToNCj4gT24gVHVl LCBOb3YgMTAsIDIwMDkgYXQgMDE6Mzc6MjdQTSAtMDYwMCwgU3RldmUgRGlzcGVuc2Egd3JvdGU6 DQo+PiBUaGlzIHdhcyBkaXNjdXNzZWQgYSBiaXQgYXQgdGhlIFNlcHQuIDI5IG1lZXRpbmcuIEkg aGFkIG9yaWdpbmFsbHkgc3VnZ2VzdGVkDQo+PiB0aGF0IHRoZSBleHRlbnNpb24gbmVlZCBub3Qg YmUgcHJlc2VudCBkdXJpbmcgaW5pdGlhbCBuZWdvdGlhdGlvbnMgYXQgYWxsLA0KPj4gYnV0IGl0 IHdhcyBwb2ludGVkIG91dCB0aGF0IG5ldHdvcmsgbWFuYWdlbWVudCBzeXN0ZW1zIG1pZ2h0IHdh bnQgdG8NCj4+IGludmVudG9yeSBwYXRjaGVkIGNsaWVudHMgYW5kIHNlcnZlcnMuDQo+IA0KPiBJ IGd1ZXNzIHdlJ2xsIHNlZSB3aGV0aGVyIHRoZSBuZWVkIHRvIGludGVyb3Agd2l0aCBicm9rZW4g c2VydmVycyAod2hpY2gNCj4gYXJlIHByb2JhYmx5IGJyb2tlbiBmb3JldmVyLCBhbmQgdGhlcmVm b3JlIHZ1bG5lcmFibGUgZm9yZXZlcikgaXMNCj4gaW1wb3J0YW50IGVub3VnaCB0aGF0IGltcGxl bWVudG9ycyB3aWxsIGhhdmUgdG8gaW5jbHVkZSBhIGtub2IgZm9yDQo+IHdoZXRoZXIgdG8gc2Vu ZCB0aGlzIGV4dGVuc2lvbiBvbiBpbml0aWFsIG5lZ290aWF0aW9ucy4gIEkgY29uc2lkZXIgdGhl DQo+IGZhY3QgdGhhdCBpdCB3aWxsIGJyZWFrIHN1Y2ggYnJva2VuIHNlcnZlcnMgYSBmZWF0dXJl LCBidXQgb25lIG11c3QgYmUNCj4gcmVhbGlzdGljIGFsc28uDQoNCkl0J3Mgb25lIHRoaW5nIHRv IHNheSwgcmVhbGlzdGljYWxseSwgc29tZSBjbGllbnQgYXBwbGljYXRpb25zIG1heSBlbGVjdA0K dG8gcHV0IHRoZWlyIHVzZXJzIGF0IHJpc2sgZm9yIHRoZSBzYWtlIG9mIGNvbnRpbnVpbmcgdG8g d29yayB3aXRoDQpkZWZlY3RpdmUgc2VydmVycy4NCg0KSXQncyBzb21ldGhpbmcgZWxzZSBlbnRp cmVseSB0byBwcm9wb3NlIHRoYXQgYW4gSUVURiBzcGVjJ3Mgb2ZmaWNpYWwNCmxhbmd1YWdlIGFu ZCByZWNvbW1lbmRlZCBwcmFjdGljZSBmb3IgaW1wbGVtZW50b3JzIHNob3VsZCBiZSB3ZWFrZW5l ZCBpbg0KY29uc2lkZXJhdGlvbiBmb3IgdGhlc2Ugbm9uY29tcGxpYW50IHN5c3RlbXMuDQoNClBl cmhhcHMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHN1Y2ggc3lzdGVtcyB3aWxsIHRha2UgdGhpcyBv cHBvcnR1bml0eSB0bw0KdXBkYXRlIHRoZW0/DQoNCllhaXIgRWxoYXJyYXIgd3JvdGU6DQo+IFRo aXMgY291bGQgYmFja2ZpcmUuIEl0IHdvdWxkIGFsbG93IGhhY2tlcnMgdG8gZGV0ZWN0IHVucGF0 Y2hlZA0KPiBjbGllbnRzLCBhbmQgZm9jdXMgdGhlaXIgYXR0YWNrcyBvbiB0aGVtLg0KDQpUaGVy ZSBhcmUgcGxlbnR5IG9mIHdheXMgZm9yIHRvIGF0dGFja2VycyB0byBmaW5nZXJwcmludCBjbGll bnRzIChsb29rZWQNCmF0IGEgdXNlci1hZ2VudCBzdHJpbmcgbGF0ZWx5PykgYW5kIGl0IGRvZXNu J3QgbWFrZSBzZW5zZSB0byBtYWtlIGxpZmUNCmRpZmZpY3VsdCBmb3IgdGhvc2Ugd2hvIGhhdmUg YSBsZWdpdGltYXRlIG5lZWQgZm9yIHRoZSBkYXRhLg0KDQpBZ2Fpbiwgd2hlcmUgdGhlcmUgYXJl IHRyYWRlLW9mZnMgYWZmZWN0aW5nIHNlY3VyaXR5IGFuZA0KaW50ZXJvcGVyYWJpbGl0eSwgbGV0 IHVzIGZhdm9yIHRoZSBzaWRlIG9mIGltcGxlbWVudGF0aW9ucyB0aGF0IHdpbGwNCmZvbGxvdyB0 aGUgc3BlY3MgYW5kIHJlY29tbWVuZGF0aW9ucyBvdmVyIHRob3NlIHdoaWNoIGRvIG5vdC4NCg0K LSBNYXJzaA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Rscw0K From Nicolas.Williams@sun.com Tue Nov 10 13:39:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C5E3A6960 for ; Tue, 10 Nov 2009 13:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.018, 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 ez-3UU2TsHVS for ; Tue, 10 Nov 2009 13:39:46 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id EE5103A67C2 for ; Tue, 10 Nov 2009 13:39:41 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAALe7pe013400 for ; Tue, 10 Nov 2009 21:40:07 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 nAALe6pi003377 for ; Tue, 10 Nov 2009 14:40:06 -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 nAALL3Vk012955; Tue, 10 Nov 2009 15:21:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAALL2e0012954; Tue, 10 Nov 2009 15:21:02 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 10 Nov 2009 15:21:02 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091110212102.GF1105@Sun.COM> References: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> <20091110203245.GB1105@Sun.COM> <4AF9D868.1030206@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF9D868.1030206@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:39:47 -0000 On Tue, Nov 10, 2009 at 03:17:28PM -0600, Marsh Ray wrote: > It's one thing to say, realistically, some client applications may elect > to put their users at risk for the sake of continuing to work with > defective servers. > > It's something else entirely to propose that an IETF spec's official > language and recommended practice for implementors should be weakened in > consideration for these noncompliant systems. Indeed. And I don't propose the latter. Instead, if we must say the sky will now be we should also caveat that it will likely continue to be blue for a long time. > Perhaps those responsible for such systems will take this opportunity to > update them? One should hope so. > Yair Elharrar wrote: > > This could backfire. It would allow hackers to detect unpatched > > clients, and focus their attacks on them. > > There are plenty of ways for to attackers to fingerprint clients (looked > at a user-agent string lately?) and it doesn't make sense to make life > difficult for those who have a legitimate need for the data. Agreed. Also, looking vulnerable and being vulnerable are not the same thing. From uri@ll.mit.edu Tue Nov 10 13:41:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679473A6B64 for ; Tue, 10 Nov 2009 13:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeMm-73RCe+6 for ; Tue, 10 Nov 2009 13:41:38 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 877603A68C5 for ; Tue, 10 Nov 2009 13:41:38 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAALg0Na012613; Tue, 10 Nov 2009 16:42:00 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAafa4zJ; Tue Nov 10 16:20:02 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Tue, 10 Nov 2009 16:20:02 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'marsh@extendedsubset.com'" Date: Tue, 10 Nov 2009 16:19:23 -0500 Thread-Topic: [TLS] TLSrenego - current summary of semantics and possibilities Thread-Index: AcpiSysjhGpjvZMuQTGXaeJ6uZw4BgAAGTtG Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3CD@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:41:39 -0000 TWFyc2gsDQoNCkNhbm5vdCBhZ3JlZSBtb3JlLiANCg0KKEluIGZhY3QgSSdtIHN1cnByaXNlZCB0 aGF0IGl0IGhhZCB0byBiZSBzdGF0ZWQhIDotKQ0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCkZyb206IHRscy1ib3VuY2VzQGlldGYub3JnIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4N ClRvOiBOaWNvbGFzIFdpbGxpYW1zIDxOaWNvbGFzLldpbGxpYW1zQHN1bi5jb20+DQpDYzogdGxz QGlldGYub3JnIDx0bHNAaWV0Zi5vcmc+DQpTZW50OiBUdWUgTm92IDEwIDE2OjE3OjI4IDIwMDkK U3ViamVjdDogUmU6IFtUTFNdIFRMU3JlbmVnbyAtIGN1cnJlbnQgc3VtbWFyeSBvZiBzZW1hbnRp Y3MgYW5kIHBvc3NpYmlsaXRpZXMNCg0KTmljb2xhcyBXaWxsaWFtcyB3cm90ZToNCj4gT24gVHVl LCBOb3YgMTAsIDIwMDkgYXQgMDE6Mzc6MjdQTSAtMDYwMCwgU3RldmUgRGlzcGVuc2Egd3JvdGU6 DQo+PiBUaGlzIHdhcyBkaXNjdXNzZWQgYSBiaXQgYXQgdGhlIFNlcHQuIDI5IG1lZXRpbmcuIEkg aGFkIG9yaWdpbmFsbHkgc3VnZ2VzdGVkDQo+PiB0aGF0IHRoZSBleHRlbnNpb24gbmVlZCBub3Qg YmUgcHJlc2VudCBkdXJpbmcgaW5pdGlhbCBuZWdvdGlhdGlvbnMgYXQgYWxsLA0KPj4gYnV0IGl0 IHdhcyBwb2ludGVkIG91dCB0aGF0IG5ldHdvcmsgbWFuYWdlbWVudCBzeXN0ZW1zIG1pZ2h0IHdh bnQgdG8NCj4+IGludmVudG9yeSBwYXRjaGVkIGNsaWVudHMgYW5kIHNlcnZlcnMuDQo+IA0KPiBJ IGd1ZXNzIHdlJ2xsIHNlZSB3aGV0aGVyIHRoZSBuZWVkIHRvIGludGVyb3Agd2l0aCBicm9rZW4g c2VydmVycyAod2hpY2gNCj4gYXJlIHByb2JhYmx5IGJyb2tlbiBmb3JldmVyLCBhbmQgdGhlcmVm b3JlIHZ1bG5lcmFibGUgZm9yZXZlcikgaXMNCj4gaW1wb3J0YW50IGVub3VnaCB0aGF0IGltcGxl bWVudG9ycyB3aWxsIGhhdmUgdG8gaW5jbHVkZSBhIGtub2IgZm9yDQo+IHdoZXRoZXIgdG8gc2Vu ZCB0aGlzIGV4dGVuc2lvbiBvbiBpbml0aWFsIG5lZ290aWF0aW9ucy4gIEkgY29uc2lkZXIgdGhl DQo+IGZhY3QgdGhhdCBpdCB3aWxsIGJyZWFrIHN1Y2ggYnJva2VuIHNlcnZlcnMgYSBmZWF0dXJl LCBidXQgb25lIG11c3QgYmUNCj4gcmVhbGlzdGljIGFsc28uDQoNCkl0J3Mgb25lIHRoaW5nIHRv IHNheSwgcmVhbGlzdGljYWxseSwgc29tZSBjbGllbnQgYXBwbGljYXRpb25zIG1heSBlbGVjdA0K dG8gcHV0IHRoZWlyIHVzZXJzIGF0IHJpc2sgZm9yIHRoZSBzYWtlIG9mIGNvbnRpbnVpbmcgdG8g d29yayB3aXRoDQpkZWZlY3RpdmUgc2VydmVycy4NCg0KSXQncyBzb21ldGhpbmcgZWxzZSBlbnRp cmVseSB0byBwcm9wb3NlIHRoYXQgYW4gSUVURiBzcGVjJ3Mgb2ZmaWNpYWwNCmxhbmd1YWdlIGFu ZCByZWNvbW1lbmRlZCBwcmFjdGljZSBmb3IgaW1wbGVtZW50b3JzIHNob3VsZCBiZSB3ZWFrZW5l ZCBpbg0KY29uc2lkZXJhdGlvbiBmb3IgdGhlc2Ugbm9uY29tcGxpYW50IHN5c3RlbXMuDQoNClBl cmhhcHMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHN1Y2ggc3lzdGVtcyB3aWxsIHRha2UgdGhpcyBv cHBvcnR1bml0eSB0bw0KdXBkYXRlIHRoZW0/DQoNCllhaXIgRWxoYXJyYXIgd3JvdGU6DQo+IFRo aXMgY291bGQgYmFja2ZpcmUuIEl0IHdvdWxkIGFsbG93IGhhY2tlcnMgdG8gZGV0ZWN0IHVucGF0 Y2hlZA0KPiBjbGllbnRzLCBhbmQgZm9jdXMgdGhlaXIgYXR0YWNrcyBvbiB0aGVtLg0KDQpUaGVy ZSBhcmUgcGxlbnR5IG9mIHdheXMgZm9yIHRvIGF0dGFja2VycyB0byBmaW5nZXJwcmludCBjbGll bnRzIChsb29rZWQNCmF0IGEgdXNlci1hZ2VudCBzdHJpbmcgbGF0ZWx5PykgYW5kIGl0IGRvZXNu J3QgbWFrZSBzZW5zZSB0byBtYWtlIGxpZmUNCmRpZmZpY3VsdCBmb3IgdGhvc2Ugd2hvIGhhdmUg YSBsZWdpdGltYXRlIG5lZWQgZm9yIHRoZSBkYXRhLg0KDQpBZ2Fpbiwgd2hlcmUgdGhlcmUgYXJl IHRyYWRlLW9mZnMgYWZmZWN0aW5nIHNlY3VyaXR5IGFuZA0KaW50ZXJvcGVyYWJpbGl0eSwgbGV0 IHVzIGZhdm9yIHRoZSBzaWRlIG9mIGltcGxlbWVudGF0aW9ucyB0aGF0IHdpbGwNCmZvbGxvdyB0 aGUgc3BlY3MgYW5kIHJlY29tbWVuZGF0aW9ucyBvdmVyIHRob3NlIHdoaWNoIGRvIG5vdC4NCg0K LSBNYXJzaA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Rscw0K From marsh@extendedsubset.com Tue Nov 10 13:42:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7A33A6B88 for ; Tue, 10 Nov 2009 13:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, GB_I_LETTER=-2] 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 XY5Zp8vqIlga for ; Tue, 10 Nov 2009 13:42:05 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 66C073A6B87 for ; Tue, 10 Nov 2009 13:42:05 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N7yTw-0001pL-F3; Tue, 10 Nov 2009 21:42:32 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 267176678; Tue, 10 Nov 2009 21:42:29 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/V9nquu7P+4Os27mCbFYJyf53D5L5p0h0= Message-ID: <4AF9DE40.60903@extendedsubset.com> Date: Tue, 10 Nov 2009 15:42:24 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911102101.nAAL1Ai9025439@fs4113.wdf.sap.corp> In-Reply-To: <200911102101.nAAL1Ai9025439@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:42:06 -0000 Martin Rex wrote: > If you lock down established identites, then I do not see a problem with this. Really, it's the upper layers that define how 'identity' is to be interpreted. TLS may know that the certs on one end or the other is the same, but that is not the same as saying that the actual app-layer identities are interchangeable. >> I do see however, that data probably needs to stop flowing after sending >> a Finished message until receiving the peer's Finished message, but >> that affects only one direction and last for one round trip, not two. > > Why Finished? I think its everything following the ChangeCipherSpec. For all the reasons that the Finished message was added to the protocol? Hmmm, is app data allowed prior to the first finished message? No way, couldn't happen. > Sending an alert when that happens and closing the connection > is fine with me. Certainly preferable to passing something unexpected. > I'm wondering whether there are application that actively abuse > this feature and would break if the TLS implementation would exhibit > semantics similar to those I outlined above and fail with an error > if the TLS implementation would reject application data while > performing the renegotiation handshake. I believe that there are TLS library implementations that conduct renegotiation transparently to the application code unless the app specifically requests it. Really there are a few missing letters in the plaintext alphabet. Handshake - A marker, encodes identity info. 0x00 - 0xFF traditional data byte values. EOD - End of data, like EOF. Without that 'handshake' value actually there in the middle of the plaintext buffered data coming out of the API, I don't know how application code can get this right. I haven't seen a TLS library API that defines things that way though. Many provide a callback for the identity change, but it's unclear what happens to buffered plaintext at the time it's called. > What about the application data sent between the ChangeCipherSpec > and the Finished messages? Possibly Handshake is really two messages, HandshakeCCS and HandshakeFinished. If app data is prohibited before the first Finished, and the RI ext strongly ties the sessions together, does this issue go away? - Marsh From ynir@checkpoint.com Tue Nov 10 13:53:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA423A6B65 for ; Tue, 10 Nov 2009 13:53:25 -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 5f48IAVc7rCV for ; Tue, 10 Nov 2009 13:53:24 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 53A883A6977 for ; Tue, 10 Nov 2009 13:53:24 -0800 (PST) X-CheckPoint: {4AF9DDD2-9-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E135C29C00F; Tue, 10 Nov 2009 23:53:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B581929C002; Tue, 10 Nov 2009 23:53:50 +0200 (IST) X-CheckPoint: {4AF9DDD1-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAALroc6026264; Tue, 10 Nov 2009 23:53:50 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 10 Nov 2009 23:53:52 +0200 From: Yoav Nir To: "mrex@sap.com" , Marsh Ray Date: Tue, 10 Nov 2009 23:53:51 +0200 Thread-Topic: [TLS] draft-rescorla-tls-renegotiate and MITM resistance Thread-Index: AcpiRVRY/rugjbG1TuuwsSqYkAg6LwACPu0d Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF7E@il-ex01.ad.checkpoint.com> References: <4AF8E755.5020208@extendedsubset.com> from "Marsh Ray" at Nov 9, 9 10:08:53 pm,<200911102034.nAAKYjkA023781@fs4113.wdf.sap.corp> In-Reply-To: <200911102034.nAAKYjkA023781@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" , "Nicolas.Williams@sun.com" Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:53:25 -0000 Martin Rex wrote: > Marsh Ray wrote: >> >> Nicolas Williams wrote: >> > On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote: >> >> I whish there was a constraint that an identity/certificate that has >> >> been established for a party during the TLS handshake MUST not change >> >> during re-negotiation, >> >> Hmm, few questions about that plan: >> >> Is this currently a defined concept in TLS: equivalence of identity? > > blob_compare(current-cert-blob,new-cert-blob) > > Everything more complicated should be an apps issue--provided that > the apps has provided "convincing arguments" to the TLS implementation > (i.e. correctly instrumented the relevant APIs) > that it is competent to perform such a re-authentication as a result > of an identity change during renegotiation. I think it's enough to blob-compare the subject DN. As long as both certifi= cates validate, and the subjects are the same, it's enough for "equivalence= of identity". I guess applications may introduce more relaxed rules of ide= ntity equivalence (such as matching CN), but matching DN should be enough e= ven for the TLS protocol. An API for the application to determine if old identity is equivalent to th= e new identity sounds good, but I don't think it would be used correctly in= practice. The rule for matching two different certificates for the same EE= may not be product-specific or implementation-specific, but may be specifi= c for the installation. A certain organization gave everyone one certificat= e for their identity, and another for their job. Matching the two certific= ates involved querying a directory to find our whether this individual actu= ally had that position. It's an abuse of PKIX, and no product would be read= y to employ such logic, unless it was written locally by the IT department = of that organization.=20 So I think as much of the logic as possible should be in the TLS layer, rat= her than the application. From mrex@sap.com Tue Nov 10 14:24:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5373F3A6BB4 for ; Tue, 10 Nov 2009 14:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 30a6wFKYYf0J for ; Tue, 10 Nov 2009 14:24:52 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 6E24D3A696C for ; Tue, 10 Nov 2009 14:24:50 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAAMPFxg019293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 23:25:15 +0100 (MET) From: Martin Rex Message-Id: <200911102225.nAAMPElc000249@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Tue, 10 Nov 2009 23:25:13 +0100 (MET) In-Reply-To: <4AF9D413.7090408@pobox.com> from "Michael D'Errico" at Nov 10, 9 12:58:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:24:53 -0000 Michael D'Errico wrote: > > > It is possible that a TLS client may not want to assert the TLS extension > > Renegotiation_Info in an initial ClientHello because of interoperability > > concerns with an installed base of not-quite-spec-compliant servers. > > Then it will end up buying a lot of pizza. What you're asking for is to discontinue talking to the entire installed base of SSL&TLS implementations. i.e. clients should only talk to updated servers (which means they must be updated clients). What about a transistion period? (A world-wide "SSL/TLS flag day" is probably unlikely) How do you determine the end of the transition period, i.e. the point in time where clients discontinue to servers that were not updated? > > Simply finishing the *initial* handshake completes the attack! (The > server saw it as a renegotiation, not the client.) But you do realize that it is an attack on the server? And do you further realize, that it is a problem of the server that request or at least allow renegotiation -- those that reject renegotiation are _not_ vulnerable. The MITM only makes you talk to someone. Considering how careless some security folks invent means to coerce someones software to talk to someone else (e.g. certificate URL TLS extension, AIA in X.509 certs), I don't feel it is fair to hold the TLS clients responsible for the problem. What you're asking for means that the Browsers should discontinue their re-connect fallback with a SSLv3 ClientHello, because the MITM could be able to coerce the browsers to do it. > > To protect against this, the only thing that a client can do is include > the empty renegotiation info extension. If the server returns it and > the handshake completes, there is no MITM. In fact if you were to then > renegotiate, you wouldn't need the extension (!) because you are already > certain that the handshake was with the server and not the MITM. HUH? The Renegotiation_Info is required for cryptographic binding during the renegotiation handshake. Without it, there is zero protection. > > There are a few possible results of sending the extension: > > a) the server responds with the extension > b) the server responds without including the extension > c) the server "crashes" because of the extension You have forgotten d) the server sends a fatal handshake alert e) the server closes the network connection > > > Overloading ("abusing") the semantics of other regular elements > > of an SSL/TLS handshake that have a lesser likelihood to upset > > legacy servers. > > > > - Assign one (or two) specific ciphersuite IDs that the client > > can include in the ciphersuites list which signal the clients > > notion of the connection state (initial vs. renegotiation) > > to the server. > > > > - Assign one (or two) compression algorithm IDs that the client > > can include in the supported compression algorithms list which > > signal the clients notion of the connection state (initial vs. > > renegotiation) to the server. > > I would not like to see this kind of solution. If code has to change, > Do The Right Thing. The IETF should provide solutions to the _real_ world. Limiting our solutions to an ideal world of academic purity will hurt the entire community of end users around the world. To me it looks like the TLS WG did not sufficiently care and push that implementations support the "official" extensibility provided already in the SSLv3 protocol (ClientHelloExtension), therefore we may have to resort to (ab)using the purpose of other extensibility options provided in the protocol that have a significantly higher interoperability among implementations. Assigning a ciphersuite IDs for the purpose of signaling support for TLS extension Renegotiation_Info in a initial handshake on a connection (as seen by the client) and including that ID in the ciphersuites list offered by the client might offend/confuse less of the old servers than a TLS client extension or a client.version != 0x03,0x00 It might be OK for an updated client to always send the TLS extension Renegotiate_Info with the verify_data from the client.finished message on a renegotiation handshake. In that case, we would not need to signal the clients notion of "initial vs. renegotiate" with an additional re-purposed ciphersuite ID. Even if _you_ can update all _your_ clients and server that you are using, this does not make the other non-patched (but also not vulnerable) servers go away. The problem that were facing right now is not caused by those servers. It's _our_ fault (Netscape and the IETF TLS WG), because _we_ created this problem with a design flaw in the protocol. So if _we_ are not trying to provide a solution in a fashion that breaks the least amount of the installed base, then we're not acting responsibly. That would amount to shifting blame / passing the buck, it would not be the engineering solution that the community expects from us. When thinking about re-purposing other areas of the exiting protocol, our concerns should be more along the lines: what will break if we do that? who might be confused by this change, and what problems may arise from such confusion? can the re-purposing lead to a new security problem by itself? How good can we interop-test this? Personally, I think that religious beliefs about protocol purity are much more important for new protocol design and forward interoperability issues. They are at most marginal when trying to fix a problem that is more than 14-years old would require then entire world to update in order to protect a small amount of people against a small amount of servers that will irresponsibly continue to make assumptions accross TLS session boundaries of an unprotected TLS renegotiation. -Martin From frantz@pwpconsult.com Tue Nov 10 14:31:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB24A28C21A for ; Tue, 10 Nov 2009 14:31:51 -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 XICBYtQJUEHz for ; Tue, 10 Nov 2009 14:31:50 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id A686B28C1FF for ; Tue, 10 Nov 2009 14:31:50 -0800 (PST) Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N7zG5-0006rv-Tj for tls@ietf.org; Tue, 10 Nov 2009 17:32:18 -0500 Date: Tue, 10 Nov 2009 14:32:15 -0800 From: Bill Frantz To: "'tls@ietf.org'" X-Priority: 3 In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF7E@il-ex01.ad.checkpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec796ab95d1f84a3e0b1d8df097478696c9d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.34 Subject: Re: [TLS] To API or not X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:31:51 -0000 I would like to add a voice in favor of considering abstract APIs in TLS. I see abstract APIs as a series of statements like, "The API SHOULD provide a way for the application to validate and approve the public key of the other end." Background: For many years the E language project , has been considering moving from our home-brew protocol VatTP to TLS. The last coherent thing I wrote discussing the issue was: I think the attributes we want to preserve from the existing VatTP are: Perfect forward security - Symmetric encryption and MAC keys exist only for the duration of the connection. They can not be recovered after the endpoints have removed them from memory. Distributed public key authentication - The sturdy-refs held by a vat contain enough information to authentic the public key sent by the remote vat, so additional mechanisms should be avoided. The system uses only known-secure algorithms, modes, and protocols. When I wrote = , there was confusion in my mind between supporting SSL and using SSL. In our case, we want to use SSL/TLS, and do not need to worry about any of the many CipherSuites (for example TLS_NULL_WITH_NULL_NULL), which are not applicable to our use. The CipherSuites (from RFC 4346 and RFC 3268) which seem most applicable to VatTP are: TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA - This CipherSuite uses the same algorithms as the current VatTP. All are somewhat dated. TLS_DH_DSS_WITH_AES_128_CBC_SHA and TLS_DH_DSS_WITH_AES_256_CBC_SHA - These update 3DES to the spiffy new AES. When two vats connect, they exchange public keys. The vats check the public key they receive against the SHA1 hash in any sturdy refs to be used, providing assurance that the remote vat is indeed the correct vat. This procedure is quite different from the certificate authority procedure used by standard SSL/TLS. It is not clear that all SSL/TLS libraries will have the user-exits to support this form of authentication. It may be necessary to adopt an new approach to provide distributed public key authentication. It would help this process if an RFC gave an idea of what interfaces one should expect from a library API. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"We used to quip that "password" is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.periwinkle.com | learned anything about security?" -- Bruce Schneier From mrex@sap.com Tue Nov 10 14:57:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172983A6B89 for ; Tue, 10 Nov 2009 14:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 IUxANgKvlOLc for ; Tue, 10 Nov 2009 14:57:44 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id EF3AE3A6B7D for ; Tue, 10 Nov 2009 14:57:43 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAAMw8xN014688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 23:58:08 +0100 (MET) From: Martin Rex Message-Id: <200911102258.nAAMw6Ah002480@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Tue, 10 Nov 2009 23:58:06 +0100 (MET) In-Reply-To: <4AF9DE40.60903@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 03:42:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:57:45 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > > If you lock down established identites, then I do not see a problem with this. > > Really, it's the upper layers that define how 'identity' is to be > interpreted. TLS may know that the certs on one end or the other is the > same, but that is not the same as saying that the actual app-layer > identities are interchangeable. One can not blindly rely on apps to do authentication, let alone do it consistently multiple times. Therefore the default should be exact identity match. I think that an administrative change to the identity ought to have an effect on TLS communication established with that identity/credentials, or it is (a) a security problem and (b) a support nightmare. If an apps protocol is so broken that it keeps running for weeks after an administrative change but will fail a reboot, then this is a support nightmare. Similarly, if an application wants TLS to use OCSP and also wants TLS to keep established session running for days or weeks ignoring certificate expiration and revocation status, then something about such an apps security requirements is fundamentally flawed. > > >> I do see however, that data probably needs to stop flowing after sending > >> a Finished message until receiving the peer's Finished message, but > >> that affects only one direction and last for one round trip, not two. > > > > Why Finished? I think its everything following the ChangeCipherSpec. > > For all the reasons that the Finished message was added to the protocol? > > Hmmm, is app data allowed prior to the first finished message? No way, > couldn't happen. We're talking about renegotiation, not the initial handshake. The current TLS spec contains a requirement that application data can be arbitrarily interleaved with handshake message during renegotiation. Application data uses a different record type at the SSL/TLS record layer than handshake messages. The MAC for the finished messages covers only the handshake messages, it entirely ignores all interleaved application data records. -Martin From mike-list@pobox.com Tue Nov 10 15:57:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06AB3A6A2B for ; Tue, 10 Nov 2009 15:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs7zsj1vq0YA for ; Tue, 10 Nov 2009 15:57:30 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id C6B353A69CA for ; Tue, 10 Nov 2009 15:57:30 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C6EF57B81B for ; Tue, 10 Nov 2009 18:57:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=GPP5xcV34Rek 14RcBBv4Fv9vjKc=; b=kvCNfds5BVaKk2gpe/AvpeIXbm/DB/Es/dvlLviuBpeQ FB5ejfhcEICivggzLjH/Ehh3nYaJNZqn34ydnSbA/r+f5pmEk6Rt+9Vh+MX2I82c x81hqtjOZyoXu/5KcYAgU3ej5G/gOT+Y1vpbnZN/5+xUL+EPulIJgqk3b7hRcsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=UPblOV gg2Vh6jz8cFqLTKg2weJZmwb8kyfZJTWm3IIe7qjdnFmKXZZR1MP5LntajAzTFbd wi2HCHXQ33+zyYwZHkq2Jd93DZuYfebWnWAKGcIGxRdYeZjnbCf0I/1vUjoyYdyZ AflElIMgMs3LMggj/YtwCt5jgYyYVvAmb4ANM= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C313D7B819 for ; Tue, 10 Nov 2009 18:57:57 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 4A5F47B818 for ; Tue, 10 Nov 2009 18:57:57 -0500 (EST) Message-ID: <4AF9FE4E.5050001@pobox.com> Date: Tue, 10 Nov 2009 15:59:10 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911102101.nAAL1Ai9025439@fs4113.wdf.sap.corp> In-Reply-To: <200911102101.nAAL1Ai9025439@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: DEC3E7AE-CE54-11DE-8EB4-7B3EEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:57:31 -0000 > What about the application data sent between the ChangeCipherSpec > and the Finished messages? I don't think application data should be (allowed to be) sent between ChangeCipherSpec and Finished. Should it be required for a fatal alert to be sent if such data is received? That would make sense. > Since the current SSL&TLS specs are completely ambiguous, you can > not claim "if your TLS API was able to tell you exactly where in > the application data stream", because currently no such semantics > exist! Two independent implementations of TLS that claim to > tell you exactly where the position is may identify entirely > different positions -- and with the current spec, it is impossible > to decide where the position should be. I disagree. When you receive the ChangeCipherSpec, the new parameters take effect; the Finished message has to immediately follow to verify the handshake succeeded. Verification of the Finished message signals the end of the old session and the beginning of the new. This would require no application data be sent between CCS and Finished, but that should be a requirement anyway. And it would be surprising to learn about an implementation that doesn't generate Finished immediately after generating the CCS. >> That would catch the MITM attack being discussed now. > > We're going to plug that MITM attack with secure renegotiation. Sure, but my point was that if these semantics had existed, this MITM attack might not have been possible. Or rather, it would have been easier to see the problem of applying the new credentials to the old request retroactively. I think it would be valuable for an API to add these semantics even with the addition of secure renegotiation. > But that will not affect the miserable ambiguity for where the > original session ends and the new session starts if we do allow > established identities to change during renegotiation. The CCS/Finished tells you where to draw the line. > To fix that, we will have to spell out the precise semantics > in a specification. IMHO, the cleanest would be to disallow > application data transfer during a renegotiation handshake. This should be up to the particular application. If rekeying is the reason for the renegotiation, you want to keep data flowing as much as possible. For changing identities, an application might forbid data flow, or it may not. >> Also silently dropping data never seems like the right thing to do IMHO. > > _I_ did not write _silent_ dropping. Dropping and aborting is fine. > Dropping in the sense of "MUST NOT make it available to the application". OK, but I would advocate MUST make available to the application and provide an indication of where the renegotiation finished. The problem with HTTPS is that the request line is sent before the handshake even starts, and then once completed, that request line is reused under the new credentials. HTTP(S) needs a way to ask the client to resend its entire request. Mike From mike-list@pobox.com Tue Nov 10 16:33:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6973F3A6828 for ; Tue, 10 Nov 2009 16:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6O2xyODunum for ; Tue, 10 Nov 2009 16:33:45 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 4E8F63A691A for ; Tue, 10 Nov 2009 16:33:45 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6D6307BBB3 for ; Tue, 10 Nov 2009 19:34:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=HPSlsc7bFNrG zM3XWRVy6hmYgxM=; b=xLLkt/rIdpplvDKSwfYHl40fxlCm+SCYVG/lp4ePbYHt XHsDCjHuOMZaDUcnIWysUmiqlKVylWn59gPoWMBqGXwdAOBgNFdqQfqZv1ReEW7b 2NQDlBU69QgM7HhkIqRRjgMGEF9/+CQCLRPVDZhwNeVhJMJK8LhTrwX4/l43FRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ftoNcz hpSaPhnsO2F+hU53USzg1jyqOlfujuRj7akg3d4ONva4Hz6WjsiBmu5N9bDCGV0a q76MLE1AmIEeW4Ia9lUGQ8NScod4wHefzyzt7VZWwFvmNiTL9/EAiCK55XxPp54B dS7jm9M91VNyHu2z/H0vIXtAiOJxlPNY9Wz7o= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 68F437BBB2 for ; Tue, 10 Nov 2009 19:34:12 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id BC9807BBAF for ; Tue, 10 Nov 2009 19:34:11 -0500 (EST) Message-ID: <4AFA06CC.2080703@pobox.com> Date: Tue, 10 Nov 2009 16:35:24 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911102225.nAAMPElc000249@fs4113.wdf.sap.corp> In-Reply-To: <200911102225.nAAMPElc000249@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: EEF2ADC2-CE59-11DE-B713-7B3EEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:33:46 -0000 > What you're asking for is to discontinue talking to the entire installed > base of SSL&TLS implementations. i.e. clients should only talk to > updated servers (which means they must be updated clients). I'm not asking for that. People seem confused about who sees the renegotiation. The client *does not* see a renegotiation in the MITM attack. It simply connects once giving its credentials, and the attack is complete. > What about a transistion period? > (A world-wide "SSL/TLS flag day" is probably unlikely) Yes, very unlikely. >> Simply finishing the *initial* handshake completes the attack! (The >> server saw it as a renegotiation, not the client.) > > But you do realize that it is an attack on the server? I just learned of the "confused deputy" attack and it appears that this is an example of that, with the server acting as the confused deputy. The server is attacked, but the client is also a victim because they need to spend the time and energy convincing their credit card company they didn't order something. > And do you further realize, that it is a problem of the server > that request or at least allow renegotiation -- those that reject > renegotiation are _not_ vulnerable. Agreed. > Considering how careless some security folks invent means to coerce > someones software to talk to someone else (e.g. certificate URL TLS extension, > AIA in X.509 certs), I don't feel it is fair to hold the TLS clients > responsible for the problem. They are not responsible, but they need to be given a defense mechanism. If they choose not to use the mechanism (i.e. by not sending the extension on initial connect), they are not going to be protected by that mechanism. > What you're asking for means that the Browsers should discontinue > their re-connect fallback with a SSLv3 ClientHello, because the > MITM could be able to coerce the browsers to do it. He can indeed. This is a really bad flaw. I'm saying that it's risky to fall back, but I'm sure that won't stop everyone from doing it. >> To protect against this, the only thing that a client can do is include >> the empty renegotiation info extension. If the server returns it and >> the handshake completes, there is no MITM. In fact if you were to then >> renegotiate, you wouldn't need the extension (!) because you are already >> certain that the handshake was with the server and not the MITM. > > HUH? The Renegotiation_Info is required for cryptographic binding > during the renegotiation handshake. Without it, there is zero protection. From just the client's perspective, all it needs is for its initial handshake to have sent and received an empty renegotiation info extension. Once that handshake completes, it knows that there is no MITM. From then on, it doesn't need secure renegotiation; it can only be talking to the same server. From the server's perspective, though, it does need the cryptographic binding since it can't tell if a renegotiation is real or proxied. >> There are a few possible results of sending the extension: >> >> a) the server responds with the extension >> b) the server responds without including the extension >> c) the server "crashes" because of the extension > > You have forgotten > d) the server sends a fatal handshake alert > e) the server closes the network connection (e) is the same as (c), and (d) can be forged too. >>> Overloading ("abusing") the semantics of other regular elements >>> of an SSL/TLS handshake that have a lesser likelihood to upset >>> legacy servers. >>> >>> - Assign one (or two) specific ciphersuite IDs that the client >>> can include in the ciphersuites list which signal the clients >>> notion of the connection state (initial vs. renegotiation) >>> to the server. >>> >>> - Assign one (or two) compression algorithm IDs that the client >>> can include in the supported compression algorithms list which >>> signal the clients notion of the connection state (initial vs. >>> renegotiation) to the server. >> I would not like to see this kind of solution. If code has to change, >> Do The Right Thing. > > The IETF should provide solutions to the _real_ world. > Limiting our solutions to an ideal world of academic purity will > hurt the entire community of end users around the world. If it's not possible to Do The Right Thing, then I am onboard with doing whatever it takes. Hijacking a ciphersuite number wouldn't be the end of the world. Mike From mrex@sap.com Tue Nov 10 16:57:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144913A69C4 for ; Tue, 10 Nov 2009 16:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 9bSvmQTjX6Sx for ; Tue, 10 Nov 2009 16:57:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 10B5D3A67B6 for ; Tue, 10 Nov 2009 16:57:48 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAB0wFSl022031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Nov 2009 01:58:15 +0100 (MET) From: Martin Rex Message-Id: <200911110058.nAB0wEUB009635@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 11 Nov 2009 01:58:14 +0100 (MET) In-Reply-To: <4AFA06CC.2080703@pobox.com> from "Michael D'Errico" at Nov 10, 9 04:35:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:57:50 -0000 Michael D'Errico wrote: > > > What you're asking for is to discontinue talking to the entire installed > > base of SSL&TLS implementations. i.e. clients should only talk to > > updated servers (which means they must be updated clients). > > I'm not asking for that. People seem confused about who sees the > renegotiation. The client *does not* see a renegotiation in the MITM > attack. It simply connects once giving its credentials, and the attack > is complete. It doesn't see one in the scenarios described by Marsh. The client will see an renegotiation in the scenario I posted to this list. > > > HUH? The Renegotiation_Info is required for cryptographic binding > > during the renegotiation handshake. Without it, there is zero protection. > > From just the client's perspective, all it needs is for its initial > handshake to have sent and received an empty renegotiation info extension. > Once that handshake completes, it knows that there is no MITM. From then > on, it doesn't need secure renegotiation; it can only be talking to the > same server. So if I mount the attack I described on your client, and use the empty TLS extension in the sess1 handshake between your client and my MITM, then your client is going to renegotiate blindly with the server to which I'm connecting it? Not good. Your fix is incomplete. Here's a mean out-of-context quote from RFC-5246: :-D D.4. Implementation Pitfalls [...] TLS protocol issues: [...] - Do you support renegotiation, both client and server initiated? -Martin From mrex@sap.com Tue Nov 10 17:39:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EED3A6BBB for ; Tue, 10 Nov 2009 17:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.103, 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 jXJNeMmBsvVM for ; Tue, 10 Nov 2009 17:39:04 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 62D693A6999 for ; Tue, 10 Nov 2009 17:39:04 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAB1dUo4026253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Nov 2009 02:39:30 +0100 (MET) From: Martin Rex Message-Id: <200911110139.nAB1dTH7011810@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 11 Nov 2009 02:39:29 +0100 (MET) In-Reply-To: <4AF9FE4E.5050001@pobox.com> from "Michael D'Errico" at Nov 10, 9 03:59:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:39:05 -0000 Michael D'Errico wrote: > > I disagree. When you receive the ChangeCipherSpec, the new parameters > take effect; the Finished message has to immediately follow to verify > the handshake succeeded. Verification of the Finished message signals > the end of the old session and the beginning of the new. Correct. This is what rfc5246 (TLS 1.2) specified in 7.4.9 Finished message when describing the handshake protocol. Unfortunately there is a slightly confusing disagreement with the description of the SSL Record protocol (which is a logically seperate thing and often also a seperate sofwarer layer). As mentionend in a previous message, the final paragraph of 6.2.1 Fragmentation in the description of the Record Layer Protocol says this to implementors: Note: Data of different TLS record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. If a company subscribes to agile software development with Scrum and assigns the implementation of the TLS record layer and of the TLS handshake protocol to different Scrum teams, you may be surprised with the result on this point of the spec. :-/ > > > But that will not affect the miserable ambiguity for where the > > original session ends and the new session starts if we do allow > > established identities to change during renegotiation. > > The CCS/Finished tells you where to draw the line. If the server implementation that you're looking at uses a callback scheme similar to OpenSSL, then the application might have hardwired the update of the client authentication state (as seen by the app) to the callback that is called when processing the clients certificate verify message. At that point, the session is still in the clear for an attacking MITM, and that MITM might start inserting application records that the server will receive at a point where it thinks the client is authenticated (which it is, just that the client authentication is tied to an encrypted channel that is still being negotiated and has not yet been confirmed for the current session yet... Does OpenSSL offer a callback for the finished messsage of a renegotiation, and which OpenSSL-based server is using that callback? I would be OK with interleaving application data with handshake message for the case where TLS enforces a lockdown of the communicating identities. I really don't like to allow both, change of identities during renegotiation _and_ arbitrary interleaving of application data with the renegotiation handshake messages. Applications may get this wrong easily. For earthbound TLS connections a rekeying of a TLS connection through renegotiation while application data continues to flow is probably not an issue. It might become an issue for a link to a space vehicle further out (like a moon of jupiter), where one might want to continue transfering a few gigabytes of data while the TLS renegotiation (for the purpose of rekeying) is performed... -Martin From mike-list@pobox.com Tue Nov 10 17:40:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B437C28C218 for ; Tue, 10 Nov 2009 17:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 TdLuDMvla9t9 for ; Tue, 10 Nov 2009 17:40:53 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id DD60528C205 for ; Tue, 10 Nov 2009 17:40:52 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 02CBC7C156 for ; Tue, 10 Nov 2009 20:41:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=buKeZ4cf3YpT lSNA5tGAz/vePQs=; b=L+eZY7SOVgiWICCzuClOqxVq9L1uci2169Hp96Av8O3Q txcQw8ogLuL4sMND4GQyLWCd1q3Q2nxgwhiNYChGtsySgyorYuSMw8i+DAhGwcr8 L3k4RA3DHimDPHchcfyr4npaXVnJGzj8s7/Jzy+c154wh11S2r3T+5FvdIVVODA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=kavZII nmxxsO7byd2MIsIby4O3J0gejo9ol4ArP81e1YWYz7kQC0tb4JMlkBPqn8m9YJVX 3iS5d5TzSL3JMeiamG/DzXKto/f4SCs1d1OiNYSSmpaspTW9yO3pQqQ9UPKfiBcI tEG8yRIDVXjD5cvGkMhvNiLT9uA9CAuhV/OZw= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id F39457C155 for ; Tue, 10 Nov 2009 20:41:19 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id A027C7C151 for ; Tue, 10 Nov 2009 20:41:19 -0500 (EST) Message-ID: <4AFA1689.5010301@pobox.com> Date: Tue, 10 Nov 2009 17:42:33 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911110058.nAB0wEUB009635@fs4113.wdf.sap.corp> In-Reply-To: <200911110058.nAB0wEUB009635@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 4F90331C-CE63-11DE-A1FE-7B3EEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:40:53 -0000 > So if I mount the attack I described on your client, and use the > empty TLS extension in the sess1 handshake between your client and > my MITM, then your client is going to renegotiate blindly with the > server to which I'm connecting it? Not good. Your fix is incomplete. I don't remember exactly your version of the attack, but if my client connects to a MITM, it will notice that the server certificate is wrong. I don't support DH_anon if that was required in your attack. Mike From marsh@extendedsubset.com Tue Nov 10 19:59:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C93E3A6A62 for ; Tue, 10 Nov 2009 19:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkMqvGX4HPIK for ; Tue, 10 Nov 2009 19:59:10 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 68CA73A6901 for ; Tue, 10 Nov 2009 19:59:10 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N84Mr-000A2n-M0 for tls@ietf.org; Wed, 11 Nov 2009 03:59:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id EF5F46678 for ; Wed, 11 Nov 2009 03:59:36 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18T96kKl7w5+7S4ESNZ+9jo1wBFUYqiqkE= Message-ID: <4AFA36A8.9010805@extendedsubset.com> Date: Tue, 10 Nov 2009 21:59:36 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911102225.nAAMPElc000249@fs4113.wdf.sap.corp> <4AFA06CC.2080703@pobox.com> In-Reply-To: <4AFA06CC.2080703@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:59:11 -0000 Michael D'Errico wrote: >> What you're asking for is to discontinue talking to the entire installed >> base of SSL&TLS implementations. i.e. clients should only talk to >> updated servers (which means they must be updated clients). > > I'm not asking for that. Even if Michael were, is there a choice? Is it even that unprecedented? Many endpoints no longer talk SSLv2. Presumably there was at least some software that once spoke earlier variants. Why were they abandoned, was it for saving bytes? Probably not. Did it make or save anybody much money? Probably not, SNI would long have been adopted if money were a sufficient motivator. No, earlier versions were abandoned because they were found to be less-than-ideal in the security department. This weakness is one of the last nails in the coffin for SSLv3, doomed from the start due to its lack of proper extensibility. It seems appropriate since it was 3.0 that quietly introduced this renegotiation bug. >> What about a transistion period? >> (A world-wide "SSL/TLS flag day" is probably unlikely) > > Yes, very unlikely. In some sense, SSLv3 was given the "legacy" label in January 1999, the date on RFC 2246 defining TLS 1.0. Who can complain after having been given 11 years' notice? For fixing TLS, there will certainly be a transition period the length of which will be determined by vendors, admins, and users as always. >>> Simply finishing the *initial* handshake completes the attack! (The >>> server saw it as a renegotiation, not the client.) >> >> But you do realize that it is an attack on the server? > [] > The server is attacked, but the client is also a victim because they > need to spend the time and energy convincing their credit card company > they didn't order something. It's an attack on a protocol which both parties are counting on for secure communications. There's nothing inherent in it that favors the security of one side over the other. >> And do you further realize, that it is a problem of the server >> that request or at least allow renegotiation -- those that reject >> renegotiation are _not_ vulnerable. > > Agreed. What if variants of the attack allow MITM to renegotiate with the client and inject data towards it? Doesn't the server application have just as much an interest in the integrity of the message as the client app does? Would you want to exchange critical secret documents with someone who was known to fall for simple email scams? > He can indeed. This is a really bad flaw. I'm saying that it's risky to > fall back, but I'm sure that won't stop everyone from doing it. I believe the key is correct information at the appropriate times. I personally would expect my browser to warn me if it was falling back to a less secure communication path. Users should expect to be given both complete raw information and synthesized recommendations such that they can 1) make an informed decision, 2) not be talked-down to, 3) learn something if they're in that mood. >>>> - Assign one (or two) specific ciphersuite IDs that the client >>>> can include in the ciphersuites list which signal the clients >>>> notion of the connection state (initial vs. renegotiation) >>>> to the server. >>>> >>>> - Assign one (or two) compression algorithm IDs that the client >>>> can include in the supported compression algorithms list which >>>> signal the clients notion of the connection state (initial vs. >>>> renegotiation) to the server. >>> I would not like to see this kind of solution. If code has to change, >>> Do The Right Thing. A simple 'renegotiating' flag has been proposed several times, but I don't think it adequately addresses the problem (binding the sessions over a single connection). Now MITM just has to put the client in some state such that the client believes he's renegotiating (without losing the connection crypto state or having some private key). It's certainly allowed for a conformant TLS client to be willing to renegotiate with MITM. I believe there are actual applications that may do that (intentionally or not). Perhaps it could be useful for SSLv3 though. Really though, we need to smuggle as much content as we can from the previous Finished messages. For example, probably no one would mind if we used some of those bottom bits of the GMT time in the ClientHello "random". We could probably put a few bits in the random area, too. After all, if they were willing to throw away 30+ bits of entropy (13% of it!) just to send the current time, surely we could use some space for verify data. Just 10 bits could make the attack 1000x harder. The same trick could be used to smuggle Finished verify data in the Server Hello as well. Thinking about it, the Hello messages are passed under the same crypto params as the verify data was originally, so it's not disclosing anything new. They also cannot be manipulated to assume certain values without breaking the hash in way that would be catastrophic even without renegotiation. They are statistically psuedorandom. One thing is that the Finished verify data is longer than the Hello.Random. Go figure. So we might take a subset of its bits, or they could be distributed as a statistical "watermark" on top of actual random data. For a worst-case estimate we could assume verify data are altogether free of entry. Even then we could make the MITM's job about a billion times harder at the cost of only another 13% of entropy from the random pool. Seems like something along these lines might work. This may be cryptographically dumb in some obvious way. I haven't thought about it much until just now and obviously it would need review. >> The IETF should provide solutions to the _real_ world. >> Limiting our solutions to an ideal world of academic purity will >> hurt the entire community of end users around the world. There are many, many deployments of TLS that will upgrade both endpoints to the most secure version the millisecond it becomes available from their vendors. They are very much in the real world. - Marsh From jsalowey@cisco.com Tue Nov 10 21:15:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7AD3A6820 for ; Tue, 10 Nov 2009 21:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 TF6zJ2DfJWoQ for ; Tue, 10 Nov 2009 21:15:06 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C71D83A6A39 for ; Tue, 10 Nov 2009 21:15:06 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPHW+UqrR7H+/2dsb2JhbADEfZhPhDwE X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="269286725" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 05:15:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAB5FYvE011593 for ; Wed, 11 Nov 2009 05:15:34 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.3959); Tue, 10 Nov 2009 21:15:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 21:15:33 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised TLS Agenda Thread-Index: Acpijf59gS3lsolFRYu0uekTuf64IQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 11 Nov 2009 05:15:34.0802 (UTC) FILETIME=[FF623F20:01CA628D] Subject: [TLS] Revised TLS Agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:15:07 -0000 In order to make time to discuss the recent vulnerability I am revising the TLS meeting agenda. Documents that are not working group items are only given enough time to introduce their topic. If we have time after the discussion of the vulnerability and the proposed fix then we may have extended discussion on these topics. I have also been able to arrange for Webex for this meeting, details will follow. =20 A. Administrivia (5 min) - Agenda Bashing=20 - Scribes - Blue Sheets B. Working Group Documents (5 min) - draft-ietf-tls-rfc4366-bis-06=20 - draft-ietf-tls-rfc4347-bis-03 =20 - draft-ietf-tls-cached-info-02=20 C. Additional PRF Input (5 min) draft-solinas-tls-additional-prf-input-01.txt=20 D. EMV support for TLS-PSK (5 min) draft-urien-tls-psk-emv-00.txt pro E. TLS Renegotiation Vulnerability (40 min) draft-rescorla-tls-renegotiation-00.txt F. Multiple OCSP draft (Time Permitting) draft-pettersen-tls-ext-multiple-ocsp-00.txt G. DTLS Heartbeat (Time Permitting) draft-seggelmann-tls-dtls-heartbeat-01.txt=20 From Pasi.Eronen@nokia.com Wed Nov 11 01:05:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3472328B56A for ; Wed, 11 Nov 2009 01:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 Gmqv-xN6EARC for ; Wed, 11 Nov 2009 01:05:13 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 32C903A69AD for ; Wed, 11 Nov 2009 01:05:12 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAB95GNL016205; Wed, 11 Nov 2009 11:05:37 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:05:35 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:05:36 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:05:31 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 11 Nov 2009 10:05:24 +0100 From: To: , Date: Wed, 11 Nov 2009 10:05:20 +0100 Thread-Topic: [TLS] TLSrenego - current summary of semantics and possibilities Thread-Index: AcpiO/1MyR/4JmGwRxehwQk6vAbUhwAcKhyg Message-ID: <808FD6E27AD4884E94820BC333B2DB774F30DD16C4@NOK-EUMSG-01.mgdnok.nokia.com> References: <4AF99E04.3060604@pobox.com> from "Michael D'Errico" at Nov 10, 9 09:08:20 am <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> In-Reply-To: <200911101928.nAAJSGjI020038@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2009 09:05:31.0076 (UTC) FILETIME=[1E9A9840:01CA62AE] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - current summary of semantics and possibilities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 09:05:15 -0000 Martin, I think we should provide *some* way to make this secure while still allowing "fallback to less advanced TLS handshakes" (e.g. from "TLS 1.2 with extensions" to "TLS 1.0 without any extensions", or even "SSLv3 without any extensions" -- the specifics vary from one implementation to another, but I think "without extensions" is one common part). Those fallbacks aren't going to go away any time=20 soon... Of the possibilities listed in your email, my preference would to allocate a cipher suite number that means "I support the renegotiation extension, but chose not to include it" (perhaps because an earlier connection with the extensions failed -- which could have been caused by the attacker). (If I recall right, some tests I run around 2006 suggested that some servers didn't like ClientHello's proposing non-NULL compression algorithms -- so a magic compression algorithm number might lead to interop problems, too. But AFAIK all servers properly ignore=20 cipher suite numbers they don't support...) Best regards, Pasi (speaking as individual contributor, not wearing any hats)=20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Martin Rex > Sent: 10 November, 2009 21:28 > To: Michael D'Errico > Cc: tls@ietf.org > Subject: [TLS] TLSrenego - current summary of semantics and > possibilities >=20 > Michael D'Errico wrote: > > > > A client that wants protection from this attack MUST send the > extension > > in its initial handshake. Why don't you want to do that? >=20 > If there were only well-behaved servers out there, there would not > be any problem. >=20 > The default configuration of MSIE6 on WinXP to disable TLSv1.0, as well > as newer browsers providing a reconnect fallback to SSLv3-only > ClientHello > indicate that there is an installed base of TLS servers that either > predates the SSLv3 internet-draft from Nov,18th 1996 or is defective. >=20 > There used to be a draft draft-pettersen-tls-interop-experience-xx.txt > (I have archived a -00 that expired oct-2006), which describes the > mess around spec non-compliance. TLS-extensions are covered in section > 4. >=20 > What it seems to indicate, in essence, is that the for maximum > interoperability with the installed base of (broken) servers out there, > you use a SSLv3 ClientHello with (0x03,0x00) in the client.version > and _no_ TLS extensions. >=20 > So conservative clients that do not want to implement reconnect > fallbacks may have a problem with the recommendation to always > use a TLS extension. >=20 >=20 >=20 > There are a number of things we would like to achieve with a fix: >=20 > - provide a method for secure renegotiation in the future >=20 > - deprecate the traditional renegotiation >=20 > - provide a secure base for the (previously flawed) assumptions > of servers when performing a renegotiation to request a > client certificate. >=20 >=20 > in oder to achieve this, we should probably make the following > recommendations: >=20 > - if a TLS client (any protocol version, including SSLv3) performs > renegotiation (i.e. sends a ClientHello over an established > TLS session with a ciphersuite other than TLS_NULL_WITH_NULL_NULL), > then it SHOULD always and unconditionally use the TLS extension > Renegotiation_Info containing the verify_data of the > client.finished > handshake message from the active TLS session, > The TLS client should do that even when it did not send the > TLS extension Renegotiation_Info with and empty extension data > in the initial TLS handshake on a connection! >=20 > Lacking application level re-connect provisions for forward- > incompatible > SSL/TLS servers, a TLS client might not want to sent the TLS > extension > in the initial ClientHello of a connection. >=20 > If the presence of the TLS extension Renegotiation_Info causes the > server to abort the TLS connection, then that > server is not capable of secure renegotiation, and the TLS client > should abort the Handshake with an error and close the connection > in order to protect the client and the clients credential from > abuse with servers that are still vulnerable to the TLS > renegotiation problem. >=20 > - A TLS server (any protocol version, including SSLv3) should require > the presence of a TLS extension Renegotiation_Info for _every_ > renegotiation handshake. >=20 > If the TLS extension Renegotiation_Info is absent from the > ClientHello > received on an active TLS session, the server should abort the > connection. (add Alert here) >=20 > If the TLS extension Renegotiation_Info is present, then the TLS > server > MUST verify the contained verify_data of the client.finished > message > as known to the client with its own memorized client.finished > message from the SecurityParameters of the current TLS connection > state. >=20 > If the comparison of the verify_data from the client.finished > messages fails, the server MUST abort the connection. >=20 > When the client's and the server's notion of the verify_data from > the previous TLS session compare equal, the server MUST send back > the TLS extension RenegotiationInfo with in a ServerHelloExtension > containing the verify_data from the client.finished message and > the verify_data from the server.finished message. >=20 > - A TLS client (any protocol version, including SSLv3) that receives > the TLS extension Renegotiation_Info in a ServerHello extension > must compare the extension data with its own SecurityParameters > in the TLS connection state. >=20 > If the Renegotiation_Info with empty extension_data is received > on a client's initial TLS handshake, everything is fine >=20 > If the Renegotiation_Info with empty extension_data is received > on an active TLS session, the client MUST abort the handshake > with an error and close the connection. >=20 > If the Renegotiation_Info with non-empty extension_data is received > on a client's initial TLS handshake, the client MUST abort the > handshake > with an error and close the connection. >=20 > If the Renegotiation_Info with non-empty extension_data is received > on a client's renegotiation handshake, the client MUST compare the > contained verify_data of the server-memorized client.finished and > server.finished messages with its own memorized verify_data for > both finished messages in the SecurityParameters of the TLS > connection > state for the current session. > - if they compare equal, everything is fine > - if they do not match, the client MUST abort the handshake and > close the connection. >=20 >=20 >=20 > It is possible that a TLS client may not want to assert the TLS > extension > Renegotiation_Info in an initial ClientHello because of > interoperability > concerns with an installed base of not-quite-spec-compliant servers. >=20 > What other strategies could be used on the initial handshake on a > connection with lesser side effects that a TLS extension > Renegotiation_Info > with empty extension_data? >=20 >=20 > Overloading ("abusing") the semantics of other regular elements > of an SSL/TLS handshake that have a lesser likelihood to upset > legacy servers. >=20 > - Assign one (or two) specific ciphersuite IDs that the client > can include in the ciphersuites list which signal the clients > notion of the connection state (initial vs. renegotiation) > to the server. >=20 > - Assign one (or two) compression algorithm IDs that the client > can include in the supported compression algorithms list which > signal the clients notion of the connection state (initial vs. > renegotiation) to the server. >=20 > I assume that a Client->Server signalling through a special cipher > suite > might be the easy to implement for clients and expect that it has the > least side effects on handshakes with old servers. >=20 > Fancy compression algs might be less digestable to old servers. >=20 >=20 > Both of these (one or two fany ciphersuites in the ciphersuite > list of the client) can only be used for signalling from client > to server, not in the direction server to client. >=20 >=20 > What could be used to signal from the server to the client that the > client should send the TLS extension Renegotiation_Info in the > ClientHello of a renegotiation handshake if the client does not > want to send the TLS extension in the initial handshake of a > connection? >=20 > We could define a new TLS handshake message "RenegotiationRequest" > to be sent instead of a "HelloRequest". This would be an option for > those servers, that will abort the handshake and connection > if the client does not send the TLS extension Renegotiation_Info. >=20 > The purpose of a RenegotiationRequest would be to encourage clients to > send the TLS extension Renegotiation_Info, in order to keep existing > usage scenarios usable. The message itself is not protected, but > that doesn't matter. The servers decision for success or failure > of the renegotiation depends only and entirely on the use of > the TLS extension Renegotiation_Info in the renegotiation handshake > and successful verification of the verify_data from the > client.finished handshake message of the active TLS session. >=20 >=20 >=20 > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Pasi.Eronen@nokia.com Wed Nov 11 01:26:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C163A6A10 for ; Wed, 11 Nov 2009 01:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 UbtKojcUvva7 for ; Wed, 11 Nov 2009 01:26:16 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D9BBE3A69DC for ; Wed, 11 Nov 2009 01:26:15 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAB9QBV3002220; Wed, 11 Nov 2009 11:26:38 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:26:31 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:26:26 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 11 Nov 2009 10:26:26 +0100 From: To: , Date: Wed, 11 Nov 2009 10:26:24 +0100 Thread-Topic: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt Thread-Index: AcphZl0IRV0SUUsnQJa6bArduTagPQBSSGSg Message-ID: <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> <4AF83FB9.9060302@drh-consultancy.demon.co.uk> <20091109175954.8DF8F69E5CB@kilo.networkresonance.com> In-Reply-To: <20091109175954.8DF8F69E5CB@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2009 09:26:26.0932 (UTC) FILETIME=[0B270340:01CA62B1] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 09:26:17 -0000 Eric Rescorla wrote: > I don't think the problem here is really the code point assignment. >=20 > I would imagine the IESG and IANA to be pretty good about doing > advance assignments once the WG has converged on the exact contents > of the extension. I know we had pretty good consensus within a > smaller group, but if when we run it by some cryptographers they say > it's insecure we'll need to change it, at which point it won't > really help to have deployed code with the "early" code point. I think this is one of those cases where an exception to the usual procedures might be in order, but the "once the WG has converged on the exact contents" is an important point here. It's relatively rare that the -00 version of some internet draft and the final RFC are actually interoperable. Using the same extension number for multiple incompatible versions of the draft is probably not a good idea (and probably not very secure, either -- if the handshake fails, you don't know if it's due to an attack or just interoperability problem, and the latter might be much more likely), and I'd like to avoid allocating multiple extension numbers for different versions of the draft, too. I certainly hope the WG converges on the contents relatively fast. The TLS WG is meeting tomorrow (Thursday), so we'll see soon. Best regards, Pasi From lists@drh-consultancy.demon.co.uk Wed Nov 11 10:59:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03D93A6957 for ; Wed, 11 Nov 2009 10:59:07 -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 ixQ5pUfIBMKA for ; Wed, 11 Nov 2009 10:59:06 -0800 (PST) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by core3.amsl.com (Postfix) with ESMTP id DC1553A6B00 for ; Wed, 11 Nov 2009 10:59:05 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:53540 helo=[192.168.7.8]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10587) with esmtpa (authdaemon_plain:drh) id 1N8IPh-0002yf-E6 (Exim 4.69) (return-path ); Wed, 11 Nov 2009 18:59:29 +0000 Message-ID: <4AFB0995.8060504@drh-consultancy.demon.co.uk> Date: Wed, 11 Nov 2009 18:59:33 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> <4AF83FB9.9060302@drh-consultancy.demon.co.uk> <20091109175954.8DF8F69E5CB@kilo.networkresonance.com> <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 18:59:07 -0000 Pasi.Eronen@nokia.com wrote: > Eric Rescorla wrote: > >> I don't think the problem here is really the code point assignment. >> >> I would imagine the IESG and IANA to be pretty good about doing >> advance assignments once the WG has converged on the exact contents >> of the extension. I know we had pretty good consensus within a >> smaller group, but if when we run it by some cryptographers they say >> it's insecure we'll need to change it, at which point it won't >> really help to have deployed code with the "early" code point. > > > > I think this is one of those cases where an exception to the usual > procedures might be in order, but the "once the WG has converged on > the exact contents" is an important point here. It's relatively rare > that the -00 version of some internet draft and the final RFC are > actually interoperable. > > Using the same extension number for multiple incompatible versions of > the draft is probably not a good idea (and probably not very secure, > either -- if the handshake fails, you don't know if it's due to an > attack or just interoperability problem, and the latter might be much > more likely), and I'd like to avoid allocating multiple extension > numbers for different versions of the draft, too. > Would including a version number in the extension help? Then if the format does change implementations can indicate that it is a version they don't support or decide they are willing to support an older version. This would also cover the case where some cryptographic attack is found against the current form later. We keep the extension number but bump up the version. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Wed Nov 11 11:16:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFC83A6A8A for ; Wed, 11 Nov 2009 11:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 tskxmVFCnSbO for ; Wed, 11 Nov 2009 11:16:30 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6FC903A69E1 for ; Wed, 11 Nov 2009 11:16:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nABJGtZZ012854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Nov 2009 20:16:55 +0100 (MET) From: Martin Rex Message-Id: <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 11 Nov 2009 20:16:55 +0100 (MET) In-Reply-To: <4AFA36A8.9010805@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 09:59:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:16:32 -0000 Marsh Ray wrote: > > This weakness is one of the last nails in the coffin for SSLv3, doomed > from the start due to its lack of proper extensibility. It seems > appropriate since it was 3.0 that quietly introduced this renegotiation bug. I think you might be barking up the wrong tree. This MITM-susceptibility is _not_ a problem specific to SSLv3. It is a problem that affects the entire installed base of TLS v1.0, TLS v1.1 and TLS v1.2 in _exactly_ the same fashion. What I do NOT want to happen is that we kill the entire installed base of TLS-servers now (including TLS v1.2 servers), which is what will be doing if we disable our clients to talk to servers that are not updated -- completely independent whether these servers are actually vulnerable. As far as upgrading/fixing is concerned: I do _not_ see an issue the SSLv3 spec that would prevent the proposed fix to be used even for sessions negotiated with protocol version 0x03,0x00. There is, however, the problem with killing interoperability to an installed base by having the client unconditionally send a TLS extension in each initial ClientHello. The issue of interoperability with that installed base seems to have been sufficiently severe, that at least one Browser vendor decided to implement a re-connect retry logic with a fallback to extension-free SSLv3 ClientHello. Do you really want to say "nice work -- we want you to remove or disable the fallback and ignore your customers complaints" -- and not because that fallback is bad or because their clients have a vulnerability -- but because we believe there is going to remain a small amount of unfixed servers where the attack will remain possible (but affecting only the users/customers of that servers). > > >> What about a transition period? > >> (A world-wide "SSL/TLS flag day" is probably unlikely) > > > > Yes, very unlikely. > > In some sense, SSLv3 was given the "legacy" label in January 1999, the > date on RFC 2246 defining TLS 1.0. Who can complain after having been > given 11 years' notice? What I meant was the transition period to an area of fixed servers. We need to ship clients capable of secure renegotiation before we can disable the old renegotiation on the servers. And we need to upgrade servers to secure renegotiation before we can suggest updated clients to discontinue talking to old servers. And this is again, totally independent of the protocol version implemented by those clients and servers, it affects all of them in the exact same fashion and with the exact same severity. (actually, the likelyhood of servers implementing or agreeing to renegotiation might increase with the supported TLS version, TLS v1.1 servers are more likely to be vulnerable to MITM than SSLv3 servers, because more of them implement renegotiation). > > I personally would expect my browser to warn me if it was falling back > to a less secure communication path. Users should expect to be given > both complete raw information and synthesized recommendations such that > they can 1) make an informed decision, 2) not be talked-down to, 3) > learn something if they're in that mood. Servers performing a traditional SSL handshake is _not_ a security problem. Servers performing a traditional renegotiation is a likely a security problem. Clients can not currently notice what the server is doing, and the problem exists, because a clients initial handshake can be proxied into a servers renegotiation. A client that is performing an initial handshake does _not_ know whether there is a security problem, therefore I'm very reluctant to suggest clients to warn users when performing a traditional initial handshake. It is going to be unfair to an ever-growing number of servers. > > Really though, we need to smuggle as much content as we can from the > previous Finished messages. For example, probably no one would mind if > we used some of those bottom bits of the GMT time in the ClientHello > "random". We could probably put a few bits in the random area, too. > After all, if they were willing to throw away 30+ bits of entropy (13% > of it!) just to send the current time, surely we could use some space > for verify data. Just 10 bits could make the attack 1000x harder. Doing the secure renegotiation through the TLS extension in an official renegotiation is not the problem. Fixing means that the code will have to be changed. If the change is sufficiently small, it can be added with a relative small amount of work to servers at all protocol levels, including SSLv3. > > The same trick could be used to smuggle Finished verify data in the > Server Hello as well. The most interesting piece is actually a signaling from the server to the client that it is performing an _initial_ handshake. That is an important information that the client does not currently have. And adding such a signal might be the easiest for old servers that need neither renegotiation and neither new TLSv1.x protocol features. In principle, every element in the vanilla ServerHello might be a candidate for such signaling. But unless the client provides an indication for understanding and accepting a protocol change through a signal in ClientHello, we are extremely limited. That signaling from server to client that it is doing an initial handshake should be - fully backwards compatible with oldest clients - very very very low number of false positives Looking at SSL/TLS handshake messages from Server to Client: ServerHello (always sent) struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; } ServerHello; ServerHelloDone (not sent on Session resume, empty) struct { } ServerHelloDone; ChangeCipherSpec (not a handshake message, unprotected, empty) Finished (always sent) struct { opaque verify_data[12]; } Finished; Looking at the ServerHello contents in detail, what elements could be re-purposed in a _completely_ backwards compatible fashion: ProtocolVersion - no Random - potentially SessionID - not really CipherSuite - no CompressionMethod - no and looking at Random in detail: struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; gmt_unix_time The current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, GMT) according to the sender's internal clock. Clocks are not required to be set correctly by the basic TLS Protocol; higher level or application protocols may define additional requirements. random_bytes 28 bytes generated by a secure random number generator. So the smallest possible change to a server that could be used to signal to ANY client that it believes to be doing an initial handshake might be to set the most significant octet of the gmt_unix_time to zero in order for a server to signal in an extremely backward compatible fashion to the client that it is performing an initial TLS handshake on a connection. Unaware of how many server out in the wild do this by accident, or how many forget to use network byte order for this value (and would cause an accidental gmt_unix_time collision every 256 seconds), all of the sensible old implementations out there are going to always signal the initial handshake to conservative clients that still do not send a TLS extension in year 2106. The remaining 28 octets of the random still provide "some" amount of collision resistance against accidental challenge reuse. This change is so small, that it might even be considered for very old code in very constrained environments, e.g. like a 10+ year old satellite in orbit -- I would really like to hear from folks with such constraints think about implementing renegotiation protection with the TLS extension -- because they might have an actual need for rekeying (rather than requesting client certs) through renegotiation. The purpose of this minimalistic change is that _one_day_ we will really be able to recommend to clients/browsers that they warn when they encounter servers that do _not_ indicate when they're doing an initial handshake (either because they're old und unchanged or because someone is trying an MITM on one of the few remaining old servers that has neither been fixed nor renegotiation reliably disabled). -Martin From Yair.Elharrar@audiocodes.com Wed Nov 11 11:42:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4D33A6830 for ; Wed, 11 Nov 2009 11:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 yqN53V6+TF01 for ; Wed, 11 Nov 2009 11:42:11 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id C12473A6869 for ; Wed, 11 Nov 2009 11:42:09 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.1.65]) by incoming.audiocodes.com with ESMTP; 11 Nov 2009 21:19:18 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80::d9:1fca:eaba:8828]) by aclcas02.corp.audiocodes.com ([::1]) with mapi; Wed, 11 Nov 2009 21:43:10 +0200 From: Yair Elharrar To: "mrex@sap.com" Date: Wed, 11 Nov 2009 21:43:09 +0200 Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Thread-Index: AcpjA6RSy+d+mlNxRZa20vcq5ADrJQAAihJI Message-ID: References: <4AFA36A8.9010805@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 09:59:36 pm,<200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> In-Reply-To: <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:42:12 -0000 Martin Rex wrote: > So the smallest possible change to a server that could be used > to signal to ANY client that it believes to be doing an initial > handshake might be to set the most significant octet of the > gmt_unix_time to zero in order for a server to signal in an > extremely backward compatible fashion to the client that it > is performing an initial TLS handshake on a connection. It would probably be better if the entire 32-bit gmt_unix_time was set to o= ne of two predefined magic values: one indicating an initial connection ('I= NIT'), the other indicating a renegotiation ('RNEG'). A client receiving 'RNEG' on an initial handshake would know the session is= under attack. A client receiving 'INIT' on an initial handshake would know the session is= safe. Any other value would indicate the server is running an insecure implementa= tion. -- This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message From marsh@extendedsubset.com Wed Nov 11 11:49:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D163A698C for ; Wed, 11 Nov 2009 11:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Hf3Noez8+9Uj for ; Wed, 11 Nov 2009 11:49:05 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id A1E6B3A68B7 for ; Wed, 11 Nov 2009 11:49:05 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N8JC9-000LMU-ET for tls@ietf.org; Wed, 11 Nov 2009 19:49:33 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8BBCA6678 for ; Wed, 11 Nov 2009 19:49:31 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1//VmQV9ZbNMogbfEr+eTAAMGMnaUcs7Ok= Message-ID: <4AFB154A.9030106@extendedsubset.com> Date: Wed, 11 Nov 2009 13:49:30 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4AFA36A8.9010805@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 09:59:36 pm, <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:49:06 -0000 Yair Elharrar wrote: > Martin Rex wrote: > > It would probably be better if the entire 32-bit gmt_unix_time was > set to one of two predefined magic values: Do you know that nothing cares about the actual time encoded? Why burn 32 bits of entropy to represent one bit? > one indicating an initial > connection ('INIT'), the other indicating a renegotiation ('RNEG'). A > client receiving 'RNEG' on an initial handshake would know the > session is under attack. A client receiving 'INIT' on an initial > handshake would know the session is safe. Any other value would > indicate the server is running an insecure implementation. The problem still exists between sessions (2,3) (3,4) and so on. - Marsh From mrex@sap.com Wed Nov 11 12:08:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772A83A69B2 for ; Wed, 11 Nov 2009 12:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.152 X-Spam-Level: X-Spam-Status: No, score=-6.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 vjUcRqpEG3wC for ; Wed, 11 Nov 2009 12:08:45 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 4BF5D3A69AB for ; Wed, 11 Nov 2009 12:08:45 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nABK99wF017626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Nov 2009 21:09:10 +0100 (MET) From: Martin Rex Message-Id: <200911112009.nABK98u2017868@fs4113.wdf.sap.corp> To: Yair.Elharrar@audiocodes.com (Yair Elharrar) Date: Wed, 11 Nov 2009 21:09:08 +0100 (MET) In-Reply-To: from "Yair Elharrar" at Nov 11, 9 09:43:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:08:46 -0000 Yair Elharrar wrote: > > Martin Rex wrote: > > > So the smallest possible change to a server that could be used > > to signal to ANY client that it believes to be doing an initial > > handshake might be to set the most significant octet of the > > gmt_unix_time to zero in order for a server to signal in an > > extremely backward compatible fashion to the client that it > > is performing an initial TLS handshake on a connection. > > It would probably be better if the entire 32-bit gmt_unix_time was > set to one of two predefined magic values: one indicating an initial > connection ('INIT'), the other indicating a renegotiation ('RNEG'). > > A client receiving 'RNEG' on an initial handshake would know the > session is under attack. > A client receiving 'INIT' on an initial handshake would know the > session is safe. asctime(gmtime("INIT")) = Sun Dec 21 13:49:08 2008 GMT asctime(gmtime("RNEG")) = Fri Oct 4 04:34:15 2013 GMT In theory, 28 random octets provide sufficient room for probabilistic collision resistance, unless the server has a real shortage of randomness or a very poorly implemented function to produce the Random for the ServerHello. > Any other value would indicate the server is running an > insecure implementation. I really do not like to label these an _insecure_. Any other value gives the client no clue whether the server is doing an initial or renegotiation handshake, because it does not contain this change. -Martin From Yair.Elharrar@audiocodes.com Wed Nov 11 12:10:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50C73A6806 for ; Wed, 11 Nov 2009 12:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 GdRf0vZ1L3zh for ; Wed, 11 Nov 2009 12:10:39 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id 8A72E3A67A7 for ; Wed, 11 Nov 2009 12:10:37 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.0.13]) by incoming.audiocodes.com with ESMTP; 11 Nov 2009 21:47:47 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80:0000:0000:0000:00d9:1fca:234.186.136.40]) by aclcas.corp.audiocodes.com ([10.1.0.13]) with mapi; Wed, 11 Nov 2009 22:11:39 +0200 From: Yair Elharrar To: Marsh Ray , "tls@ietf.org" Date: Wed, 11 Nov 2009 22:07:28 +0200 Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Thread-Index: AcpjCDDFSoGFtwLTRU+rId79ipWXYgAAmd5J Message-ID: References: <4AFA36A8.9010805@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 09:59:36 pm, <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> , <4AFB154A.9030106@extendedsubset.com> In-Reply-To: <4AFB154A.9030106@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:10:40 -0000 Marsh Ray wrote: > The problem still exists between sessions (2,3) (3,4) and so on. I'm not suggesting to remove the new extension altogether; only from initia= l ClientHellos. Once the client knows the server is patched, it will use the extension in r= enegotiations. The server should never allow renegotiations without the new extension. Yair -- This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message From mrex@sap.com Wed Nov 11 12:14:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3993A6830 for ; Wed, 11 Nov 2009 12:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 pUii+VscM-+9 for ; Wed, 11 Nov 2009 12:14:42 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A8A233A6806 for ; Wed, 11 Nov 2009 12:14:41 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nABKF7k6025238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Nov 2009 21:15:07 +0100 (MET) From: Martin Rex Message-Id: <200911112015.nABKF68b018491@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 11 Nov 2009 21:15:06 +0100 (MET) In-Reply-To: <4AFB154A.9030106@extendedsubset.com> from "Marsh Ray" at Nov 11, 9 01:49:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:14:43 -0000 Marsh Ray wrote: > > Yair Elharrar wrote: > > Martin Rex wrote: > > > > It would probably be better if the entire 32-bit gmt_unix_time was > > set to one of two predefined magic values: > > Do you know that nothing cares about the actual time encoded? > > Why burn 32 bits of entropy to represent one bit? Yair's suggestion is actually 3 states (~1.5 bits) initial, renegotiation, unknown but other than that, it also seems like waste to me to re-purpose the _entire_ 32-bits. > > > one indicating an initial > > connection ('INIT'), the other indicating a renegotiation ('RNEG'). A > > client receiving 'RNEG' on an initial handshake would know the > > session is under attack. A client receiving 'INIT' on an initial > > handshake would know the session is safe. Any other value would > > indicate the server is running an insecure implementation. > > The problem still exists between sessions (2,3) (3,4) and so on. New clients should not renegotiate with servers that lack the secure renegotiation extension. There is no problem with clients participating an initial handshake with these, provided that they can distinguish initial from renegotiation handshakes performed by the server. -Martin From rwilliams@certicom.com Wed Nov 11 12:21:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456573A69F6 for ; Wed, 11 Nov 2009 12:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 fusruPHaEus9 for ; Wed, 11 Nov 2009 12:21:17 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 8D4543A685E for ; Wed, 11 Nov 2009 12:21:15 -0800 (PST) X-AuditID: 0a401fcb-b7bb7ae000005c61-50-4afb1cd76209 Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id AD.26.23649.7DC1BFA4; Wed, 11 Nov 2009 15:21:43 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:21:42 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Wed, 11 Nov 2009 15:21:42 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4023805E5@XCH57YKF.rim.net> In-Reply-To: <4AFB154A.9030106@extendedsubset.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Thread-Index: AcpjCCHeQvhskyqzS96B/nl5lhhdkQAABhdA References: <4AFA36A8.9010805@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 09:59:36 pm, <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> <4AFB154A.9030106@extendedsubset.com> From: "Rob P Williams" To: X-OriginalArrivalTime: 11 Nov 2009 20:21:42.0562 (UTC) FILETIME=[95181020:01CA630C] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:21:18 -0000 Hi, I have a different suggestion for keeping SSLv3 safe. The problem for SSLv3 and TLS1~1.2 was created here: 5.6.9 Finished handshake_messages All of the data from all handshake messages up to but not including this message. This is only data visible at the handshake layer and does not include record layer headers. If ALL handshake messages were used - this problem would not exist. Implementations have treated 'all' as 'from the current handshake'. (TLS1.0 cemented this problem). By changing the way the Finished message is calculated - you can make SSLv3 safer. Approach: For initial handshakes - keep the calculation the same. For subsequent handshakes - append extra information to 'handshake_messages' before being hashed. This could be as simple as a counter. This could be the finished data from the previous handshake. I've attempted to draw a table of what would happen when renegotiating; OC =3D old client NC =3D new client OS =3D old server NS =3D new server OS | NS ------+----- OC | . | fail NC | fail | good OC-NS failure - is useful - it shows the attack being mitigated. NC-OS failure - is ALSO useful. By attempting to renegotiate - you can verify if you are talking to an OS or NS. -- rob | Software Developer Certicom Corp. | A susbidiary of Research In Motion Limited main | +1 905-507-4220 direct | +1 905-501-3887 rwilliams@certicom.com www.certicom.com ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ynir@checkpoint.com Wed Nov 11 12:28:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC583A6AF9 for ; Wed, 11 Nov 2009 12:28:57 -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 GJDgQQdV45x9 for ; Wed, 11 Nov 2009 12:28:56 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 429C43A6806 for ; Wed, 11 Nov 2009 12:28:33 -0800 (PST) X-CheckPoint: {4AFB1B66-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 39EF029C00B; Wed, 11 Nov 2009 22:29:01 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1A35029C002; Wed, 11 Nov 2009 22:29:01 +0200 (IST) X-CheckPoint: {4AFB1B65-2-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nABKT0c6017524; Wed, 11 Nov 2009 22:29:00 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 11 Nov 2009 22:29:02 +0200 From: Yoav Nir To: "mrex@sap.com" , Marsh Ray Date: Wed, 11 Nov 2009 22:25:09 +0200 Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Thread-Index: AcpjC7BpmLuhuu2eQBKuTOIMKn6fQgAAV/mj Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB4@il-ex01.ad.checkpoint.com> References: <4AFB154A.9030106@extendedsubset.com> from "Marsh Ray" at Nov 11, 9 01:49:30 pm,<200911112015.nABKF68b018491@fs4113.wdf.sap.corp> In-Reply-To: <200911112015.nABKF68b018491@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:28:57 -0000 I disagree that it's a waste to repurpose the entire 32-bit value. Sure we= could use only the top two bits (00 for initial, 01 for reneg - it's after= 2004, so all times have MSB=3D1), but then you can't tell the difference b= etween a patched TLS implementation and an implementation with its system c= lock not set properly. A 32-bit magic value (the date of the first chartering of the TLS WG and th= e date of the vulnerability being published?) will reduce the likelihood of= error to negligible. Two bits won't ________________________________________ From: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Martin Rex [= mrex@sap.com] Sent: Wednesday, November 11, 2009 22:15 To: Marsh Ray Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Marsh Ray wrote: > > Yair Elharrar wrote: > > Martin Rex wrote: > > > > It would probably be better if the entire 32-bit gmt_unix_time was > > set to one of two predefined magic values: > > Do you know that nothing cares about the actual time encoded? > > Why burn 32 bits of entropy to represent one bit? Yair's suggestion is actually 3 states (~1.5 bits) initial, renegotiation, unknown but other than that, it also seems like waste to me to re-purpose the _entire_ 32-bits. From marsh@extendedsubset.com Wed Nov 11 12:42:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689333A6B11 for ; Wed, 11 Nov 2009 12:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 wjdnv7omC4AF for ; Wed, 11 Nov 2009 12:42:56 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 2F4383A684A for ; Wed, 11 Nov 2009 12:42:56 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N8K2G-000M4z-3T; Wed, 11 Nov 2009 20:43:24 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CCD466678; Wed, 11 Nov 2009 20:43:21 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Ey4MQN3iY1kcLUUZYOnWIlcmPET8kYSI= Message-ID: <4AFB21E8.7040609@extendedsubset.com> Date: Wed, 11 Nov 2009 14:43:20 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> In-Reply-To: <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:42:57 -0000 Martin Rex wrote: > Marsh Ray wrote: >> This weakness is one of the last nails in the coffin for SSLv3, doomed >> from the start due to its lack of proper extensibility. It seems >> appropriate since it was 3.0 that quietly introduced this renegotiation bug. > > I think you might be barking up the wrong tree. > > This MITM-susceptibility is _not_ a problem specific to SSLv3. > It is a problem that affects the entire installed base of > TLS v1.0, TLS v1.1 and TLS v1.2 in _exactly_ the same fashion. Yes, but TLS >= 1.0 can be fixed properly with https://datatracker.ietf.org/drafts/draft-rescorla-tls-renegotiation/ > What I do NOT want to happen is that we kill the entire installed > base of TLS-servers now (including TLS v1.2 servers), which is what > will be doing if we disable our clients to talk to servers that > are not updated -- completely independent whether these servers > are actually vulnerable. > > > As far as upgrading/fixing is concerned: I do _not_ see an issue > the SSLv3 spec that would prevent the proposed fix to be used > even for sessions negotiated with protocol version 0x03,0x00. SSL 3.0 doesn't seem to allow extensions on Server and Client Hello messages. > There is, however, the problem with killing interoperability > to an installed base by having the client unconditionally send > a TLS extension in each initial ClientHello. TLS allows extensions and specifies when they should be ignored. > The issue of interoperability with that installed base seems to > have been sufficiently severe, that at least one Browser vendor > decided to implement a re-connect retry logic with a fallback > to extension-free SSLv3 ClientHello. Maybe that was one of those "we've always done it that way" decisions that needs to be revisited. > Do you really want to say "nice work -- we want you to remove > or disable the fallback and ignore your customers complaints" -- > and not because that fallback is bad or because their clients > have a vulnerability -- but because we believe there is going > to remain a small amount of unfixed servers where the attack will > remain possible (but affecting only the users/customers > of that servers). To the extent TLS is about delivering on its stated and implied security guarantees. That may or may not meet the requirements of any specific application. > What I meant was the transition period to an area of fixed servers. > > We need to ship clients capable of secure renegotiation before we > can disable the old renegotiation on the servers. > > And we need to upgrade servers to secure renegotiation before we > can suggest updated clients to discontinue talking to old servers. The proposed draft-rescorla-tls-renegotiation "RI extension" provides a solution which restores the security of connections where both endpoints implement it. There is probably no way to restore that security without patching both endpoints. The RI extension also maintains backwards compatibility with existing conformant TLS endpoints. There are reports of some non-conformant servers that might not like seeing an extension on TLS, we can hardly ask the world to forever abandon the idea of Hello message extensions as a result! The timeframe over which users and admins move to configure their applications to deny connections with unpatched endpoints ("secure mode") is up to each individual, in conjunction with their vendors. I have opinions about it, but it really is a situation which will need informed judgement on a case-by-case basis. The timeframe over which the default settings of new installations (and late-patched existing deployments) migrates to secure mode is largely up to the TLS implementation and application vendors. > Servers performing a traditional SSL handshake is _not_ a security > problem. There are some attacks in which the client sees the renegotiation and the server only sees one connection. > Clients can not currently notice what the server is doing, and the > problem exists, because a clients initial handshake can be proxied > into a servers renegotiation. Which is particularly bad when the client is willing to provide client cert authentication in that handshake. > A client that is performing an initial handshake does _not_ know > whether there is a security problem, therefore I'm very reluctant > to suggest clients to warn users when performing a traditional > initial handshake. The client can determine if he is handshaking with an unpatched TLS server when he sees the Server Hello message without the RI extension. It sounds reasonable to me that the client might indicate this potentially-insecure situation in whatever UI or log facility the client application provides. > It is going to be unfair to an ever-growing > number of servers. No, the number of unpatched servers in the world will begin shrinking as soon as the fix becomes available. > Doing the secure renegotiation through the TLS extension in an > official renegotiation is not the problem. Fixing means that the > code will have to be changed. If the change is sufficiently small, > it can be added with a relative small amount of work to servers > at all protocol levels, including SSLv3. So SSLv3 would be retroactively given hello extensions? Sounds like a breaking change. Wouldn't it be easier to just use TLS? - Marsh From marsh@extendedsubset.com Wed Nov 11 13:22:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708023A681A for ; Wed, 11 Nov 2009 13:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 hMY36doC-r50 for ; Wed, 11 Nov 2009 13:22:51 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 8FCD63A689F for ; Wed, 11 Nov 2009 13:22:51 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N8Ker-000OCV-T1 for tls@ietf.org; Wed, 11 Nov 2009 21:23:18 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 120786678 for ; Wed, 11 Nov 2009 21:23:16 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18GKN79P8smKGnc2Cry9yIXfRjlfWE7UV4= Message-ID: <4AFB2B42.9060602@extendedsubset.com> Date: Wed, 11 Nov 2009 15:23:14 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4AFA36A8.9010805@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 09:59:36 pm, <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> <4AFB154A.9030106@extendedsubset.com> <7E1DF37F1F42AB4E877E492C308E6AC4023805E5@XCH57YKF.rim.net> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC4023805E5@XCH57YKF.rim.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 21:22:52 -0000 Rob P Williams wrote: > By changing the way the Finished message is calculated - you can make > SSLv3 safer. I think this is a good idea for SSLv3. (the proposed extension is better for TLS) > Approach: > > For initial handshakes - keep the calculation the same. > > For subsequent handshakes - > append extra information to 'handshake_messages' before being > hashed. > This could be as simple as a counter. > This could be the finished data from the previous handshake. It has to be something that MITM cannot prep the client or server into matching. A 'renegotiating' bit is not sufficient, even a counter may not be (M just renegotiates that same number of times before splicing). Is it possible to define this in terms of what already exists? E.g. simply "don't reset the handshake MAC state for renegotiations" ? > I've attempted to draw a table of what would happen when > renegotiating; > > OC = old client > NC = new client > OS = old server > NS = new server > > > OS | NS > ------+----- > OC | . | fail > NC | fail | good > > > OC-NS failure - is useful - > it shows the attack being mitigated. > NC-OS failure - is ALSO useful. > By attempting to renegotiate - you can verify if you are talking to > an OS or NS. Well, if the remote endpoint allows you to initiate a renegotiation. MS IIS for example responds with a TCP RST, other implementations may be less direct. - Marsh From rwilliams@certicom.com Wed Nov 11 14:03:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33AC3A6A11 for ; Wed, 11 Nov 2009 14:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 seCvGgtyhS08 for ; Wed, 11 Nov 2009 14:03:47 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 0505D3A6970 for ; Wed, 11 Nov 2009 14:03:45 -0800 (PST) X-AuditID: 0a401fcb-b7bb7ae000005c61-f0-4afb34dc530c Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs03ykf.rim.net (RIM Mail) with SMTP id EA.6D.23649.CD43BFA4; Wed, 11 Nov 2009 17:04:13 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 17:04:12 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Wed, 11 Nov 2009 17:04:12 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402380768@XCH57YKF.rim.net> In-Reply-To: <4AFB2B42.9060602@extendedsubset.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Thread-Index: AcpjFTQV/NMDQ0tPSM2BTkatlt7ZHgAAMHxQ References: <4AFA36A8.9010805@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 09:59:36 pm, <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> <4AFB154A.9030106@extendedsubset.com><7E1DF37F1F42AB4E877E492C308E6AC4023805E5@XCH57YKF.rim.net> <4AFB2B42.9060602@extendedsubset.com> From: "Rob P Williams" To: "Marsh Ray" , X-OriginalArrivalTime: 11 Nov 2009 22:04:12.0355 (UTC) FILETIME=[E6A80130:01CA631A] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 22:03:48 -0000 Marsh Ray wrote: > Rob P Williams wrote: > > By changing the way the Finished message is calculated - you can make > > SSLv3 safer. > > I think this is a good idea for SSLv3. (the proposed extension is better > for TLS) > > > Approach: > > > > For initial handshakes - keep the calculation the same. > > > > For subsequent handshakes - > > append extra information to 'handshake_messages' before being > > hashed. > > This could be as simple as a counter. > > This could be the finished data from the previous handshake. > > It has to be something that MITM cannot prep the client or server into > matching. A 'renegotiating' bit is not sufficient, even a counter may > not be (M just renegotiates that same number of times before splicing). The counter option would mitigate this attack, the client is at 'initial', the server is at one when the splice is attempted. The hashes in the Finished message will be different. An attacker would require both ends to handshake the same number of times (and be in sync) to make the splice possible. A client that would handshake with the attacker (to match the counter) would be susceptible to a proxy... Adding the previous finished data to the hash offers similar features to the TLS extension proposal. Instead of transmitting the channel binding explicitly, they are being compressed by MD5 and SHA1. > Is it possible to define this in terms of what already exists? E.g. > simply "don't reset the handshake MAC state for renegotiations" ? I feel that keeping the digests themselves (the bytes, or the finished data, or the counter), and not the state of the SHA1 and MD5 (which may never be used) is less resource intensive. However, keeping them running would match the 'ALL' handshake messages point above... > > I've attempted to draw a table of what would happen when > > renegotiating; > > > > OC =3D old client > > NC =3D new client > > OS =3D old server > > NS =3D new server > > > > > > OS | NS > > ------+----- > > OC | . | fail > > NC | fail | good > > > > > > OC-NS failure - is useful - > > it shows the attack being mitigated. > > NC-OS failure - is ALSO useful. > > By attempting to renegotiate - you can verify if you are talking to > > an OS or NS. > > Well, if the remote endpoint allows you to initiate a renegotiation. MS > IIS for example responds with a TCP RST, other implementations may be > less direct. Good point! An attacker could just hang up on a (current or new) client to make them think they are using a renegotiation proof IIS instance... Only seeing a correct renegotiation with a new server would verify that you are talking to a new server. -- rob | Software Developer Certicom Corp. | A susbidiary of Research In Motion Limited main | +1 905-507-4220 direct | +1 905-501-3887 rwilliams@certicom.com www.certicom.com ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jsalowey@cisco.com Wed Nov 11 15:18:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D195D3A6B64 for ; Wed, 11 Nov 2009 15:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 dHR-cmqtgV6S for ; Wed, 11 Nov 2009 15:18:21 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C8D3E3A6B62 for ; Wed, 11 Nov 2009 15:18:21 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADPV+kqrR7Ht/2dsb2JhbACkfaBMiSIEBY5eAoI/EQWBZQSBa4ol X-IronPort-AV: E=Sophos;i="4.44,726,1249257600"; d="scan'208";a="269777432" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 23:18:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABNIooR016297 for ; Wed, 11 Nov 2009 23:18:50 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:18:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 15:18:48 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Attendee Invitation for tls WebEX on Thursday -- forward to attendees! Thread-Index: AcphmL3B3NaewHeEQXebnaNrXuuD+ABjIYdw From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 11 Nov 2009 23:18:50.0192 (UTC) FILETIME=[53A7B500:01CA6325] Subject: [TLS] FW: Attendee Invitation for tls WebEX on Thursday -- forward to attendees! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:18:22 -0000 =20 **** You can forward this email invitation to attendees ****=20 Hello ,=20 IETF WG Chair WebEX invites you to attend this online meeting.=20 Topic: tls at IETF 76 Date: Thursday, November 12, 2009 Time: 3:00 pm, Japan Time (Tokyo, GMT+09:00) Meeting Number: 965 278 654 Meeting Password: tls=20 ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D130198622&UID=3D0&PW=3DN= YmJmO DA4Nzk5&RT=3DMiM0OQ%3D%3D 2. Enter your name and email address.=20 3. Enter the meeting password: tls 4. Click "Join Now".=20 To view in other time zones or languages, please click the link:=20 https://workgreen.webex.com/workgreen/j.php?ED=3D130198622&UID=3D0&PW=3DN= YmJmO DA4Nzk5&ORT=3DMiM0OQ%3D%3D=20 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.=20 Call-in toll-free number (US/Canada): 866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf=20 Access code:965 278 654=20 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 amorris1@amsl.com 1-510-492-4084=20 To add this meeting to your calendar program (for example Microsoft Outlook), click this link:=20 https://workgreen.webex.com/workgreen/j.php?ED=3D130198622&UID=3D0&ICS=3D= MI&LD =3D1&RD=3D2&ST=3D1&SHA2=3DALyZodmAXpMNKPKmuLyDtjMq38A/zyyxC20C9vo0nqE=3D&= RT=3DMiM0OQ %3D%3D=20 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php=20 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial=20 http://www.webex.com =20 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session.=20 ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From Chris.Newman@Sun.COM Wed Nov 11 15:34:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C843A6B64 for ; Wed, 11 Nov 2009 15:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 Ad7fGzxiisl0 for ; Wed, 11 Nov 2009 15:34:24 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id E3FFE3A699F for ; Wed, 11 Nov 2009 15:34:23 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABNYqR3014784 for ; Wed, 11 Nov 2009 15:34:52 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSY00100X8NGU00@fe-sfbay-09.sun.com> for tls@ietf.org; Wed, 11 Nov 2009 15:34:52 -0800 (PST) Received: from [10.0.1.3] ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSY00FUFXI1QJ10@fe-sfbay-09.sun.com>; Wed, 11 Nov 2009 15:34:51 -0800 (PST) Date: Wed, 11 Nov 2009 15:34:49 -0800 From: Chris Newman In-reply-to: <4AF455DF.5040106@stpeter.im> Sender: Chris.Newman@Sun.COM To: Peter Saint-Andre , Nikos Mavrogiannopoulos Message-id: <57839EF28A3534D8E0C69AD4@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> <4AF455DF.5040106@stpeter.im> Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:34:25 -0000 It is likely XMPP is vulnerable. IMAP and SMTP are vulnerable. The only application protocol I've studied that I believe resists the vulnerability is POP3+STLS (even pops may be vulnerable). I know of two ways to leverage the TLS re-negotiation vulnerability to attack applications: 1. Authenticating an otherwise un-trusted directive using credentials from an authorized user. As far as I know this attack only applies to HTTP-like protocols (including IPP, SIP, HTTP, WebDAV, CalDAV, etc.) due to the poor design of HTTP authentication, cookie and client certificate mechanisms. Application protocols like IMAP, POP, SMTP, XMPP, BEEP with cleanly separate not-authenticated and authenticated states are immune to this attack. 2. Having one authorized and authenticated TLS session decrypt data from a different TLS session. This attack is most severe for SMTP+STARTTLS+BDAT (since SMTP relays typically treat all senders as authenticated as long as the recipient is in the local domain), but impacts most application protocols that have a command to "send", "post", "put", "set an attribute" or perform any write operation that can subsequently be read back. In the case of IMAP, this can be used by one authorized IMAP user (someone with an account on the IMAP server) to potentially steal the login password of another IMAP user on the same server (with some IMAP client behavior caveats). It is likely that XMPP is vulnerable to attack #2. I would recommend anyone running an SMTP relay (port 25) to turn off both the STARTTLS and SMTP AUTH features immediately until this is resolved. An SMTP Submission server (port 587, RFC 4409, requires SMTP AUTH to submit mail) should keep STARTTLS enabled. Sites that have not made the split between SMTP relay and SMTP submission should do so -- they have different security properties and this is yet another reason they should be different services (either on different ports or different IP addresses). - Chris --On November 6, 2009 9:59:11 -0700 Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/5/09 2:00 PM, Nikos Mavrogiannopoulos wrote: >> Eric Rescorla wrote: >>> TLS WG members will want to check out this announcement of a >>> new attack on the TLS renegotiation logic. See here: >>> >>> http://www.extendedsubset.com/ >>> >>> The high-level summary is that the attacker negotiates TLS with the >>> server and then subsequently proxies the client's negotiation *over* >>> that channel. This allows the attacker to inject arbitrary content of >>> their choice in front of data sent from the TLS client to the TLS >>> server. This data will be treated by the server as if it came from the >>> client. Once the new handshake has finished, the attacker can't >>> do anything else useful. >> >> I'll become a bit pedantic and note here that this isn't really a TLS >> issue. We have an initial server-authenticated only session and some >> renegotiation of parameters over it to authenticate the client. However >> TLS doesn't guarantee[0] that if the renegotiation is successful >> authenticating the client, then the data from the initial session were >> also by the same authenticated client. >> Think for example a session that it is anonymous (DH). Why one should >> assume that commands over the anonymous connection are to be trusted if >> a successful renegotiation follows? >> >> So for me the issue is on HTTP's usage of the TLS protocol >> renegotiation. After a TLS renegotiation for authentication the previous >> command cache should have been cleared and reissued after negotiation. > > I tend to agree. Some folks in the XMPP community have analyzed the use > of TLS in XMPP, and their preliminary conclusion is that XMPP is not > vulnerable to this attack because the client and server are required to > clear the security context and restart the XML stream after TLS > negotiation (or renegotiation). Those who did this analysis will publish > a brief report about their findings in the near future. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkr0Vd8ACgkQNL8k5A2w/vyeqQCgpzZakXwr62UdxAHdNyqwe4xe > WEUAoMPGdY94w+/+oAv9oYC0I9iu7hnI > =sjVM > -----END PGP SIGNATURE----- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Chris.Newman@Sun.COM Wed Nov 11 15:40:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148233A6931 for ; Wed, 11 Nov 2009 15:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 4rXyCimRPixP for ; Wed, 11 Nov 2009 15:40:45 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 587B53A6B68 for ; Wed, 11 Nov 2009 15:40:45 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABNfDIj020393 for ; Wed, 11 Nov 2009 15:41:13 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSY00100X8NGU00@fe-sfbay-09.sun.com> for tls@ietf.org; Wed, 11 Nov 2009 15:41:13 -0800 (PST) Received: from [10.0.1.3] ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSY00F5UXSNQJ20@fe-sfbay-09.sun.com>; Wed, 11 Nov 2009 15:41:13 -0800 (PST) Date: Wed, 11 Nov 2009 15:41:11 -0800 From: Chris Newman In-reply-to: <20091106172323.GY1105@Sun.COM> Sender: Chris.Newman@Sun.COM To: Nicolas Williams , Nikos Mavrogiannopoulos Message-id: X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> <20091106172323.GY1105@Sun.COM> Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] TLS or HTTP issue? (was: TLS renegotiation issue) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:40:46 -0000 --On November 6, 2009 11:23:23 -0600 Nicolas Williams wrote: > This vulnerability will affect different application protocols > differently. It certainly affects HTTP. I think LDAP may not be > susceptible, but I'm not sure; I'm even less sure about IMAP. IMAP is susceptible (see my previous email). I'm fairly certain LDAP is susceptible in two ways: 1. An authorized LDAP user with permission to set and read an LDAP attribute anywhere in the DIT can likely use the TLS renegotiation attack to steal another LDAP user's simple bind password. 2. If LDAP and another vulnerable service (e.g. SMTP+STARTTLS+BDAT, IMAP, etc) have server certificates with the same hostname, then an authorized user of one of those other services can steal another user's LDAP simple bind password. - Chris From Chris.Newman@Sun.COM Wed Nov 11 15:59:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392FF3A63C9 for ; Wed, 11 Nov 2009 15:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_56=0.6, 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 NlaBjGPhfzI4 for ; Wed, 11 Nov 2009 15:59:01 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 2108F3A69DF for ; Wed, 11 Nov 2009 15:59:01 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABNxTkf021847 for ; Wed, 11 Nov 2009 15:59:29 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSY00000YJYPY00@fe-sfbay-10.sun.com> for tls@ietf.org; Wed, 11 Nov 2009 15:59:29 -0800 (PST) Received: from [10.0.1.3] ([unknown] [10.1.110.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSY00LL9YN2Y8B0@fe-sfbay-10.sun.com>; Wed, 11 Nov 2009 15:59:29 -0800 (PST) Date: Wed, 11 Nov 2009 15:59:26 -0800 From: Chris Newman In-reply-to: <200911070100.nA710jJO018486@fs4113.wdf.sap.corp> Sender: Chris.Newman@Sun.COM To: mrex@sap.com Message-id: <5F1B41A60D9D4613F01568C9@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <200911070100.nA710jJO018486@fs4113.wdf.sap.corp> Cc: tls@ietf.org Subject: [TLS] Register port for https+client cert (was Re: draft-rescorla-tls-renegotiate.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:59:02 -0000 --On November 7, 2009 2:00:45 +0100 Martin Rex wrote: > Should we ask for an additional port to be officially allocated > to http-over-ssl-with-client-cert This is a good idea. HTTP authentication is particularly badly designed, but we can't really fix it so we have to live with it. Having a separate port for HTTP-with-client-cert-mandatory where the server can "just know" that client certs will be present in the initial handshake and will never be renegotiated, and the client can "just know" it has to prompt the user for client cert selection removes some of the need for all the security "fudging" HTTP does and thus is an overall security improvement, IMHO. I would not want other protocols to copy this mess, however -- application protocols should have a clean and simple state transition between "not authenticated" and "authenticated" state. POP, IMAP, XMPP, LDAP, BEEP and even Telnet did this better than HTTP. - Chris From djhopwood@googlemail.com Wed Nov 11 16:14:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993B43A6808 for ; Wed, 11 Nov 2009 16:14:42 -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 gCB+ymJ7Rji9 for ; Wed, 11 Nov 2009 16:14:40 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id E337B3A67D1 for ; Wed, 11 Nov 2009 16:14:39 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so401025eyd.51 for ; Wed, 11 Nov 2009 16:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=pD6SWsrzyOVbymUAg9nx46/U76SmhH5ekaoqTxtkYBU=; b=At6fKW+YCGWdHGzjeVCKk0PelvmkdLZ/PNHC+DpP4JSTyCgkKt74zSavTPVMzGY1qS jouB50LLHCcyB66af4D5ztqzGadTbbeugTBb18tHfiJaODZhwpOKEn/v3GZ6RSSmnvZ8 gUeWT5+i/2pNjdevc2G8r8S1pntoF9+uuZOs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=bBE/rixe6lhVfT7v/TGQtgKL64EI+0BPmUcMpcXdfn0LSK+lCRkRe/qB8doIfPMilM DBEcn3V/xOhsQKLMbbLgkYNxQwC7FonSHHn9cBw6CUsXekHLvrWUtiIXJlCbPnXE71PD 6SfzZVSrx8btYbygSIk0gDLB1n2rfLeDBT+ZQ= Received: by 10.213.0.135 with SMTP id 7mr2829767ebb.64.1257984903163; Wed, 11 Nov 2009 16:15:03 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 23sm1753478eya.12.2009.11.11.16.15.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 16:15:02 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFB5380.50908@jacaranda.org> Date: Thu, 12 Nov 2009 00:14:56 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> <4AF83FB9.9060302@drh-consultancy.demon.co.uk> <20091109175954.8DF8F69E5CB@kilo.networkresonance.com> <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com> <4AFB0995.8060504@drh-consultancy.demon.co.uk> In-Reply-To: <4AFB0995.8060504@drh-consultancy.demon.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8FB7171F7B40D9019DC2D8B2" Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 00:14:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FB7171F7B40D9019DC2D8B2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dr Stephen Henson wrote: > Pasi.Eronen@nokia.com wrote: >> Eric Rescorla wrote: >> >>> I don't think the problem here is really the code point assignment. >>> >>> I would imagine the IESG and IANA to be pretty good about doing >>> advance assignments once the WG has converged on the exact contents >>> of the extension. I know we had pretty good consensus within a >>> smaller group, but if when we run it by some cryptographers they say >>> it's insecure we'll need to change it, at which point it won't >>> really help to have deployed code with the "early" code point. >> >> >> I think this is one of those cases where an exception to the usual >> procedures might be in order, but the "once the WG has converged on >> the exact contents" is an important point here. It's relatively rare >> that the -00 version of some internet draft and the final RFC are >> actually interoperable. It's rare for typical RFCs, but this is a very simple extension. The discussion so far has been about when clients and servers MUST or SHOULD send the extension; not about changes to its contents or meaning that would affect interoperability. If no such changes in fact occur, then I would hope that the existing extension number (0xFF01) could be assigned,= rather than assigning a new number for the sake of it. >> Using the same extension number for multiple incompatible versions of >> the draft is probably not a good idea (and probably not very secure, >> either -- if the handshake fails, you don't know if it's due to an >> attack or just interoperability problem, and the latter might be much >> more likely), and I'd like to avoid allocating multiple extension >> numbers for different versions of the draft, too. >=20 > Would including a version number in the extension help? Then if the for= mat does > change implementations can indicate that it is a version they don't sup= port or > decide they are willing to support an older version. I don't see any advantage of that over using a different extension number= , *if* the format changes. In any case, the current draft is -00, and no changes that would not be interoperable have yet been proposed. So let's avoid prematurely adding complication where it may not be needed. > This would also cover the case where some cryptographic attack is found= against > the current form later. We keep the extension number but bump up the ve= rsion. Adding a new extension would have the same effect. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig8FB7171F7B40D9019DC2D8B2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr7U4cACgkQWUc8YzyzqAd9lgD/RurUMhIWK7wsSiwDMVh1MvDF +NL3jmlNVgLfGgxrzO0A/j7JfFXpWD9KIYfubuCuMFusRfeiwxe9Gvu0LfS0e8Gh =Fg/M -----END PGP SIGNATURE----- --------------enig8FB7171F7B40D9019DC2D8B2-- From mike-list@pobox.com Wed Nov 11 16:34:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E0F3A694E for ; Wed, 11 Nov 2009 16:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 N5TtxQ8PwbZx for ; Wed, 11 Nov 2009 16:34:10 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 989733A69CA for ; Wed, 11 Nov 2009 16:34:10 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C5CAA9B27C for ; Wed, 11 Nov 2009 19:34:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=unu7QExLF18w +eJPHpvOTX/9kQE=; b=XOS7u10FXp3eYq1rRoVBWbCSsiANGVNspdh7THyn0Hog qCBbItnh+KwfCULl2eWhJDX5e1Y/Ob3BwOBeu/Ddf5DRCr8DN/u5CLEkISFcM0JH 20Kem+T/3hIR7YmrL5nL2uqn3xhNESEzdKBdTf3FzB4dNBC0yg+9XidxpzdlpWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=b0iiba PZx+cMS7sFSEBljE3mNiaP/k9nedax1/Ll1lMacFg+FZ4qqcUJGJ/kWdgEUYZ9TC TN5FyUKGBEhsCEvAWmo6YNVWLpCaL72nGUhCWXZAoNsHCoTOplsjYK+2EPS1wf58 MmUYCisN4WRbUuMpPXxt2daoBF6dBJZIR+AgE= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C1F009B27B for ; Wed, 11 Nov 2009 19:34:38 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 77AC99B27A for ; Wed, 11 Nov 2009 19:34:38 -0500 (EST) Message-ID: <4AFB584D.5080205@pobox.com> Date: Wed, 11 Nov 2009 16:35:25 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp> <4AFB21E8.7040609@extendedsubset.com> In-Reply-To: <4AFB21E8.7040609@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 291190F8-CF23-11DE-8B62-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 00:34:11 -0000 >> A client that is performing an initial handshake does _not_ know >> whether there is a security problem, therefore I'm very reluctant >> to suggest clients to warn users when performing a traditional >> initial handshake. > > The client can determine if he is handshaking with an unpatched TLS > server when he sees the Server Hello message without the RI extension. > It sounds reasonable to me that the client might indicate this > potentially-insecure situation in whatever UI or log facility the client > application provides. A MITM could remove the extension from the ServerHello to trick you into thinking the server doesn't support it. Unless you finish the handshake, you won't know. But if you do finish it, you could be attacked. Very insidious! Mike From pgut001@wintermute01.cs.auckland.ac.nz Wed Nov 11 17:22:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7E828C172 for ; Wed, 11 Nov 2009 17:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-1.429, 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 0LaLdNgsXcDk for ; Wed, 11 Nov 2009 17:22:04 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 3A07428C165 for ; Wed, 11 Nov 2009 17:22:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 748A09CDB0; Thu, 12 Nov 2009 14:22:26 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i56DCHYaLYae; Thu, 12 Nov 2009 14:22:26 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B37DA9CDFC; Thu, 12 Nov 2009 14:22:23 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N8OOF-00014c-Hj; Thu, 12 Nov 2009 14:22:23 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1N8OOF-0007Ee-BG; Thu, 12 Nov 2009 14:22:23 +1300 From: Peter Gutmann To: marsh@extendedsubset.com, mrex@sap.com, ynir@checkpoint.com In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB4@il-ex01.ad.checkpoint.com> Message-Id: Sender: pgut001 Date: Thu, 12 Nov 2009 14:22:23 +1300 Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:22:05 -0000 Yoav Nir writes: >I disagree that it's a waste to repurpose the entire 32-bit value. Sure we >could use only the top two bits (00 for initial, 01 for reneg - it's after >2004, so all times have MSB=1), but then you can't tell the difference >between a patched TLS implementation and an implementation with its system >clock not set properly. ... or an implementation that sees advertising your machine's clock skew to the world as a security weakness (which it is when it starts interacting with PKI) and sets the time field to a random value. Peter. From nelson@bolyard.me Wed Nov 11 17:27:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E5A3A6AC8 for ; Wed, 11 Nov 2009 17:27:02 -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 j9KFhSkF2yUh for ; Wed, 11 Nov 2009 17:27:01 -0800 (PST) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id 566303A63C9 for ; Wed, 11 Nov 2009 17:27:01 -0800 (PST) Received: (qmail 6348 invoked from network); 12 Nov 2009 01:27:26 -0000 Received: from unknown (24.5.142.42) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 12 Nov 2009 01:27:25 -0000 Message-ID: <4AFB64FA.1060505@bolyard.me> Date: Wed, 11 Nov 2009 17:29:30 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:27:02 -0000 At least Two implementers have read the draft differently and implemented non-interoperable implementations. The draft needs clarification. First the draft says: The "extension data" field of this extension contains a "Renegotiation_Info" structure: struct { opaque renegotiated_connection<0..255>; } Renegotiation_Info; Then it says: The contents of this extension are specified as follows. o If this is the initial handshake for a connection, then this field is of zero length in both the ClientHello and the ServerHello. One implementer interprets this to mean that the extension data field is of zero length. Another interprets it to mean that the "renegotiated_connection" field inside the Renegotiation_Info is to have zero length. This leads to two different encodings, which are: FF 01 00 00 FF 01 00 01 00 I suggest replacing "the contents of this extension" with either "The contents of the renegotiated_connection", or "the contents of the extension data field", to make this sufficiently explicit. /Nelson From ynir@checkpoint.com Wed Nov 11 17:29:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419B23A6AC8 for ; Wed, 11 Nov 2009 17:29:04 -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 qu5UvCYMIM8m for ; Wed, 11 Nov 2009 17:29:03 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4ED5E3A63C9 for ; Wed, 11 Nov 2009 17:29:03 -0800 (PST) X-CheckPoint: {4AFB61D1-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 57E1A29C00B; Thu, 12 Nov 2009 03:29:27 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3995229C002; Thu, 12 Nov 2009 03:29:27 +0200 (IST) X-CheckPoint: {4AFB61CD-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAC1TQc6021146; Thu, 12 Nov 2009 03:29:26 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 12 Nov 2009 03:29:29 +0200 From: Yoav Nir To: Peter Gutmann , "marsh@extendedsubset.com" , "mrex@sap.com" Date: Thu, 12 Nov 2009 03:28:50 +0200 Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Thread-Index: AcpjNqYAE0/wYOQTSKKkdsm15s5ikgAANcuQ Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB5@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB4@il-ex01.ad.checkpoint.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:29:04 -0000 Implementations actually do that? =20 Probably makes sense, I guess. ________________________________________ From: pgut001 [pgut001@wintermute01.cs.auckland.ac.nz] On Behalf Of Peter G= utmann [pgut001@cs.auckland.ac.nz] Sent: Thursday, November 12, 2009 03:22 To: marsh@extendedsubset.com; mrex@sap.com; Yoav Nir Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Yoav Nir writes: >I disagree that it's a waste to repurpose the entire 32-bit value. Sure w= e >could use only the top two bits (00 for initial, 01 for reneg - it's after >2004, so all times have MSB=3D1), but then you can't tell the difference >between a patched TLS implementation and an implementation with its system >clock not set properly. ... or an implementation that sees advertising your machine's clock skew to the world as a security weakness (which it is when it starts interacting wi= th PKI) and sets the time field to a random value. Peter. From pgut001@wintermute01.cs.auckland.ac.nz Wed Nov 11 17:44:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCDE28C178 for ; Wed, 11 Nov 2009 17:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.690, 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 tbSVO19TvA9h for ; Wed, 11 Nov 2009 17:44:14 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 0C7CA28C17B for ; Wed, 11 Nov 2009 17:44:13 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F2A8441416E; Thu, 12 Nov 2009 14:44:39 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JtlzcvTLPie; Thu, 12 Nov 2009 14:44:39 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D1FC9414164; Thu, 12 Nov 2009 14:44:39 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N8Ojn-0002qT-IB; Thu, 12 Nov 2009 14:44:39 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1N8Ojn-0008Fe-Hb; Thu, 12 Nov 2009 14:44:39 +1300 From: Peter Gutmann To: marsh@extendedsubset.com, mrex@sap.com, pgut001@cs.auckland.ac.nz, ynir@checkpoint.com In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB5@il-ex01.ad.checkpoint.com> Message-Id: Sender: pgut001 Date: Thu, 12 Nov 2009 14:44:39 +1300 Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:44:14 -0000 Yoav Nir writes: >Implementations actually do that? I know of at least two that do, so it's at least a nonzero result :-). There may be a lot more, since no-one checks the time and there's no obvious reason to include it in the nonce it's quicker and easier for an implementation not to bother (quite apart from any security concerns). Peter. From wtc@google.com Wed Nov 11 17:48:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58DB28C17B for ; Wed, 11 Nov 2009 17:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 CBtxYFkzyHJX for ; Wed, 11 Nov 2009 17:48:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id E0A2C28C178 for ; Wed, 11 Nov 2009 17:48:02 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id nAC1mTHL008616 for ; Thu, 12 Nov 2009 01:48:30 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257990510; bh=bYfs2AIPonw59Jw7c7BpdNH5TJI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=F+zav4ABK8e37FRLgVYItllXx+ZOEGyt1e0ZWQa7XZ8CGExV1RMcB3QhoyAo9Yznx Flpx+/HcRGz5bmXmJIaxQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=COix0V1BG4yLlj7xSSUqKYQqQMmq1rD/rOaGvn9BO1MGRI9xN9kMv/VxDvW9wFmgB F0idnMoLcg4fv3hDzcEgA== Received: from pzk33 (pzk33.prod.google.com [10.243.19.161]) by wpaz9.hot.corp.google.com with ESMTP id nAC1m9j7029624 for ; Wed, 11 Nov 2009 17:48:27 -0800 Received: by pzk33 with SMTP id 33so1161471pzk.2 for ; Wed, 11 Nov 2009 17:48:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.56.11 with SMTP id e11mr255095wfa.118.1257990506680; Wed, 11 Nov 2009 17:48:26 -0800 (PST) In-Reply-To: <4AFB64FA.1060505@bolyard.me> References: <4AFB64FA.1060505@bolyard.me> Date: Wed, 11 Nov 2009 17:48:26 -0800 Message-ID: From: Wan-Teh Chang To: Nelson B Bolyard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:48:07 -0000 On Wed, Nov 11, 2009 at 5:29 PM, Nelson B Bolyard wrote= : > At least Two implementers have read the draft differently and implemented > non-interoperable implementations. =A0The draft needs clarification. > > First the draft says: > > =A0 The "extension data" field of this extension contains a > =A0 "Renegotiation_Info" structure: > > =A0 =A0 =A0 =A0 =A0 =A0 struct { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque renegotiated_connection<0..255>; > =A0 =A0 =A0 =A0 =A0 =A0 } Renegotiation_Info; > > Then it says: > > =A0 The contents of this extension are specified as follows. > > =A0 o =A0If this is the initial handshake for a connection, then this fie= ld > =A0 =A0 =A0is of zero length in both the ClientHello and the ServerHello. > > One implementer interprets this to mean that the extension data field > is of zero length. =A0Another interprets it to mean that the > "renegotiated_connection" field inside the Renegotiation_Info is to > have zero length. =A0This leads to two different encodings, which are: > > =A0FF 01 00 00 > > =A0FF 01 00 01 00 > > I suggest replacing "the contents of this extension" with either > "The contents of the renegotiated_connection", or > "the contents of the extension data field", to make this sufficiently > explicit. This kind of ambiguity was also in the original RFC 4507 for the TLS session ticket extension, and had to be addressed in a new RFC 5077. See RFC 5077 section 1 and appendix A. Wan-Teh From nelson@bolyard.me Wed Nov 11 18:24:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31E03A67F2 for ; Wed, 11 Nov 2009 18:24:50 -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 U4bbrloS+p8N for ; Wed, 11 Nov 2009 18:24:50 -0800 (PST) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id 22D973A6828 for ; Wed, 11 Nov 2009 18:24:50 -0800 (PST) Received: (qmail 11514 invoked from network); 12 Nov 2009 02:25:18 -0000 Received: from unknown (24.5.142.42) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 12 Nov 2009 02:25:18 -0000 Message-ID: <4AFB728C.9050102@bolyard.me> Date: Wed, 11 Nov 2009 18:27:24 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <4AFB64FA.1060505@bolyard.me> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:24:51 -0000 On 2009-11-11 17:48 PDT, Wan-Teh Chang wrote: > On Wed, Nov 11, 2009 at 5:29 PM, Nelson B Bolyard wrote: >> At least Two implementers have read the draft differently and implemented >> non-interoperable implementations. The draft needs clarification. >> >> First the draft says: >> >> The "extension data" field of this extension contains a >> "Renegotiation_Info" structure: >> >> struct { >> opaque renegotiated_connection<0..255>; >> } Renegotiation_Info; >> >> Then it says: >> >> The contents of this extension are specified as follows. >> >> o If this is the initial handshake for a connection, then this field >> is of zero length in both the ClientHello and the ServerHello. >> >> One implementer interprets this to mean that the extension data field >> is of zero length. Another interprets it to mean that the >> "renegotiated_connection" field inside the Renegotiation_Info is to >> have zero length. This leads to two different encodings, which are: >> >> FF 01 00 00 >> >> FF 01 00 01 00 >> >> I suggest replacing "the contents of this extension" with either >> "The contents of the renegotiated_connection", or >> "the contents of the extension data field", to make this sufficiently >> explicit. > > This kind of ambiguity was also in the original RFC 4507 for > the TLS session ticket extension, and had to be addressed in > a new RFC 5077. See RFC 5077 section 1 and appendix A. Thanks for the tip, Wan-Teh. So, summarizing that appendix, it says that clients have two different interpretations of an empty session ticket extension, so servers should accept either one and should return an empty extension in the same format as that sent by the client. Fellow TLS WG members, Let's not repeat that for this extension. This extension hasn't been published in an RFC yet, so let's nip this in the bud, and make it completely unambiguous before that happens. /Nelson From mike-list@pobox.com Wed Nov 11 19:44:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2810F28C1CC for ; Wed, 11 Nov 2009 19:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 eHE-OVT9asRA for ; Wed, 11 Nov 2009 19:44:52 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 31E8128C1B4 for ; Wed, 11 Nov 2009 19:44:52 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3F0AC7D89A for ; Wed, 11 Nov 2009 22:45:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=PNB750YKDT4V q5cLJJ2gGBSrI5w=; b=dt7bqZssBOLwaSw5v/Ysrzv8bSLgmaLFC4aNjr7hkD0X J5Xkid1i3HVXCT3cZrGmTyKBm1lU9teAuvbzkIXMPEXR72H9KcNg1kQSFOCAgWUe bTbDr34Zp7VUT0zCBIK0mnStSBiLsQwfK9hCtnfv0+lDXyOpwqYBVxsi0bZ7gVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=KJo9/x hbgpgoljGs4hh4B4qptfunQYmiq1DeiWM40ra90Po0o3kAnvc6n32UHE3wxU7gKB q9GbFgF2YpeG5w7lmTm0F+Hr9aXR/fNP1hbu9S8iMLOPWUW/iwp4r1iM/CmqawuX Kj849K8PfKFLvjowsHd8foJuMC11yzMocxmmQ= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 37F607D899 for ; Wed, 11 Nov 2009 22:45:20 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 575657D897 for ; Wed, 11 Nov 2009 22:45:19 -0500 (EST) Message-ID: <4AFB8502.60102@pobox.com> Date: Wed, 11 Nov 2009 19:46:10 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AFB64FA.1060505@bolyard.me> <4AFB728C.9050102@bolyard.me> In-Reply-To: <4AFB728C.9050102@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CCB2A534-CF3D-11DE-9C18-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:44:53 -0000 >>> This leads to two different encodings, which are: >>> >>> FF 01 00 00 >>> >>> FF 01 00 01 00 I will selfishly vote for the second choice since that is how I implemented it, though it would be easy to change. Mike From djhopwood@googlemail.com Wed Nov 11 19:49:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4805728C1ED for ; Wed, 11 Nov 2009 19:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 CyErbw3JaICh for ; Wed, 11 Nov 2009 19:49:19 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 7595228C1AC for ; Wed, 11 Nov 2009 19:49:16 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so422319eyd.5 for ; Wed, 11 Nov 2009 19:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=aUkiKiec4EbpoxYuJ3fpeUn6OHODjUYhfupLdVsWxt4=; b=kkbY1WvGn2u/kUQYwH4SHqdDVJy3JzIEWkNY7o3TyAhhHd6sK/LFHStMv7K5f3AFFO BThLoR2bIM8FAwMj4UDw7X6+po0Iw0JY7MMU5QV2FFwKdPqBsRUiJ6z3HPmAmBBngmFG fFKpAseF6Rr/r7WQXO9D7o5OKFKwMyHgrRrbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=ZRFVucUwIwh5qmeSXS+FjaBxN2C36ORBHlMrbqYGlqXH6GeteDQZWfi+MfBMOTNTZT 4YohOwREJLZbVgxwfPge+bzv/elrP3mtP+FzHrGf79OZfZH7G6tvxanc86X6ikNdu2SR VSrPJ/0eK0YSCRDCDs93K4UPd4h9ePEOktRxA= Received: by 10.213.0.144 with SMTP id 16mr2113784ebb.38.1257997781962; Wed, 11 Nov 2009 19:49:41 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 24sm2159634eyx.37.2009.11.11.19.49.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 19:49:41 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFB859A.9000508@jacaranda.org> Date: Thu, 12 Nov 2009 03:48:42 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC2E7E8430964BB3246CE5FE1" Subject: Re: [TLS] FW: Attendee Invitation for tls WebEX on Thursday -- forward to attendees! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:49:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC2E7E8430964BB3246CE5FE1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joseph Salowey (jsalowey) wrote: > =20 > **** You can forward this email invitation to attendees ****=20 >=20 > Hello ,=20 >=20 > IETF WG Chair WebEX invites you to attend this online meeting.=20 >=20 > Topic: tls at IETF 76 > Date: Thursday, November 12, 2009 > Time: 3:00 pm, Japan Time (Tokyo, GMT+09:00) Meeting Number: 965 278 65= 4 > Meeting Password: tls=20 This announcement was sent at 2009-11-11 23:18 UTC. The meeting is at 2009-11-12 06:00 UTC. Doesn't seem likely that many new people from Europe, for example, will be joining -- even those who would have considered the renegotiation attack to be important enough to discuss at any time of day/night, given longer notice. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigC2E7E8430964BB3246CE5FE1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr7hdEACgkQWUc8YzyzqAc+3AD/VT6RqZnR3LjQKmK5VRPFsrRq 2cnk2NjnBF0IM8PbmuYA/00L18AmiFSG9GQMyHTl3fvYm6T6H43bX2XyjvvLed93 =Y/GY -----END PGP SIGNATURE----- --------------enigC2E7E8430964BB3246CE5FE1-- From djhopwood@googlemail.com Wed Nov 11 20:09:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E087B3A67A6 for ; Wed, 11 Nov 2009 20:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 LEylk5pLIZhI for ; Wed, 11 Nov 2009 20:09:59 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id BACE928C12D for ; Wed, 11 Nov 2009 20:09:58 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so458580eyd.51 for ; Wed, 11 Nov 2009 20:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=yrBVoy8ks4hPXAB770mqVAP1cfGrDTJ2DpRMRE7ABKw=; b=Zai5xCHSha0ti3iiinIBog/k3yBmFCi+ubASd6gIeLvVzBbW2I11er6iuWzEqlRZ3x kc3ul9GnAJL5Ux1Vkic5DOF1QqqKLyqeBFRVOLH2IxQlK6QDzfLDUcMvi8fmjI8Oyixt GEXPR76H7LZOTOjMVjFw+57fC9yA5BBmlNMC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=YK7/sQ4cuipuxc+twXRDkHVIvjF4qZnTnRradV4zot5VU7Ihm8X41T+g7LGHrxYgaU qW1GlCFv3Hf7NrUHbiRgsOl+sRQ6Kg6aWPMq0CP9VxaIzjtWur4b3qW7wPCYb57/C1pM LOyYFbNVFEVnUrAT62I72P4JjlupfG8qhzEa4= Received: by 10.213.100.168 with SMTP id y40mr2251431ebn.77.1257999023664; Wed, 11 Nov 2009 20:10:23 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 5sm2071430eyf.6.2009.11.11.20.10.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 20:10:23 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFB8AA8.3040802@jacaranda.org> Date: Thu, 12 Nov 2009 04:10:16 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AFB64FA.1060505@bolyard.me> <4AFB728C.9050102@bolyard.me> <4AFB8502.60102@pobox.com> In-Reply-To: <4AFB8502.60102@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA5AE084790D710E6D2F73CFD" Subject: Re: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:10:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA5AE084790D710E6D2F73CFD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: >>>> This leads to two different encodings, which are: >>>> >>>> FF 01 00 00 >>>> >>>> FF 01 00 01 00 Good catch. > I will selfishly vote for the second choice since that is > how I implemented it, though it would be easy to change. The second choice is slightly more regular, in that the empty and non-empty versions of the extension data have the same type. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigA5AE084790D710E6D2F73CFD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr7iqgACgkQWUc8YzyzqAcjoQD+M9T9/u+8ItoJPjF6TuEOTjzv Eu+ereyksZ58oD6tg/4A/jZDSKUujbb0gsxT1mqbKC8Wd1BXsmGTri/H4IhrHPaU =QF4i -----END PGP SIGNATURE----- --------------enigA5AE084790D710E6D2F73CFD-- From ekr@networkresonance.com Wed Nov 11 20:21:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FADE3A63EB for ; Wed, 11 Nov 2009 20:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.839 X-Spam-Level: X-Spam-Status: No, score=0.839 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T3+5RwiZD2X for ; Wed, 11 Nov 2009 20:21:31 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 332E23A6767 for ; Wed, 11 Nov 2009 20:21:31 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N8RC2-0004LB-00 for tls@ietf.org; Thu, 12 Nov 2009 06:21:58 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id EF62069EDB2; Wed, 11 Nov 2009 13:17:08 +0100 (CET) Date: Wed, 11 Nov 2009 13:17:08 +0100 From: Eric Rescorla To: tls@ietf.org, draft-solinas-tls-additional-prf-input@tools.ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091111121708.EF62069EDB2@kilo.networkresonance.com> Subject: [TLS] Comments on draft-solinas-tls-additional-prf-input X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:21:32 -0000 Despite not being clear on what this is for, I don't have a problem with there being a code point assigned for this extension for USG use. However, I don't think that some of the proposed uses are in fact appropriate and would like to see the document revised accordingly. In particular, there are two potential things one might be trying to do here: 1. Add additional randomness into the PRF. 2. Add structured, meaningful data into the PRF. AFAICT, the first of these is useless but harmless: useless because the security guarantees of TLS require only uniqueness of the Random values, not unpredictability, and 28 bytes is far more than required to provide a statistical guaranteee of uniqueness; harmless because the PRF can easily absorb additional new data, even if it is completely nonrandom. The second, however, is a backdoor method of extending TLS and the semantics are completely different: in order to be useful, the data in the extension must be processed and potentially checked by the other side. Several mechanisms for extending TLS already exist (TLS Extensions and then the TLS Supplemental Data message) and should not add yet another generic mechanism here. I don't have a problem with an opaque field here, since that's really just a private code point assignment. But having it have actual semantics leaks into TLS and I do object to that. DETAILED COMMENTS S 1. The mechanism described here has several desirable features which may prove useful beyond the requirements of the US Government applications. It is easy to implement, and using it adds little to the overall computation of the TLS handshake. Further, interoperability is preserved between clients that implement the extension and servers that do not, and between clients that do not implement the extension and servers that do. These really aren't generically desirable features, since they just say "this doesn't do any damage". I guess that's desirable, but the relevant quesiton is why one would want to do this at all. S 1.1. Several recommendations for key derivation call for the concatenation of additional information fields into the key derivation function when producing a shared key. For example, the specification of Alternative 1 in NIST Special Publication 800-56A ([SP800-56A]) calls for the inclusion of "OtherInfo" fields. In this case, OtherInfo contains the concatenation of a variety of mandatory and optional sub-fields. The extension described in this document provides a simple mechanism both for supplying the public information to the peer and for the inclusion of the information in the key derivation. Many other application environments require or allow similar fields. This actually seems extremely dangerous. AFAICT the point of these OtherInfo fields is that they are explicitly bound into the PRF on both sides. In order to be useful (as opposed to formally present), OtherInfo needs to be explicitly produced/verified by each side. This needs to be removed. S 3.1. The AdditionalRandom type, whose AdditionalPRFInputType value is {TBD1}, is used to add additional random values from the client and/or the server to the PRF. The size and the contents of the AdditionalPRFInputValue are undefined (other than it must be between 0 and 2^16-4 bytes). The size of the AdditionalPRFInputValue provided by the client does not indicate anything about the expected size of the AdditionalPRFInputValue from the server. So there is no way for the client to elicit a certain amount of additional random data from the server? From mike-list@pobox.com Wed Nov 11 20:22:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CF928C1DD for ; Wed, 11 Nov 2009 20:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 TaIJHxDisJ2t for ; Wed, 11 Nov 2009 20:22:09 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 27CD828C1DA for ; Wed, 11 Nov 2009 20:22:09 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 79C2C7DB92 for ; Wed, 11 Nov 2009 23:22:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=1ewCI4VWYvom IcJgZ4YtkNf1wrE=; b=aRtkZgaWp2ZMbdSecIqmhW2MpPihBBBMQERPpELQ+9Aj cU+ScOTi6Aj8YNLvHQZFhcOWcri3D1LXt0htY+SD//fnU4KeOA55ARBEkWq0RHwJ h0H+wVDPKojuRe9fOOBg1KCkxWSRBJ03qoq+awqsE4JKIDKvK1YUlfefLYpkTiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Tg2/9Q N2Fk6fswJyj+dShdAq98REV6na2hAL8GUWtnrbTXmJibzbMHayycKBqM92fRTB5z FkMkk/tApyrQewsVqdOHfwoHnCfDeiF5Ab0Jixa3xymHW85CawZoW8Pjb/IOoH0O MCpuJseAb3hOy7GPAnheXHWDkHqM5GTj7ELMI= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 779607DB91 for ; Wed, 11 Nov 2009 23:22:37 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 2380D7DB8F for ; Wed, 11 Nov 2009 23:22:36 -0500 (EST) Message-ID: <4AFB8DC0.3060502@pobox.com> Date: Wed, 11 Nov 2009 20:23:28 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AFB64FA.1060505@bolyard.me> <4AFB728C.9050102@bolyard.me> <4AFB8502.60102@pobox.com> <4AFB8AA8.3040802@jacaranda.org> In-Reply-To: <4AFB8AA8.3040802@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 0236FDEA-CF43-11DE-AFAF-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:22:10 -0000 David-Sarah Hopwood wrote: > Michael D'Errico wrote: >>>>> This leads to two different encodings, which are: >>>>> >>>>> FF 01 00 00 >>>>> >>>>> FF 01 00 01 00 > > Good catch. I can't take credit for finding that -- it was Nelson. Mike >> I will selfishly vote for the second choice since that is >> how I implemented it, though it would be easy to change. > > The second choice is slightly more regular, in that the empty and > non-empty versions of the extension data have the same type. From djhopwood@googlemail.com Wed Nov 11 21:07:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0AA3A6A1C for ; Wed, 11 Nov 2009 21:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 s67bV8RYkgcw for ; Wed, 11 Nov 2009 21:07:19 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 517A53A68E6 for ; Wed, 11 Nov 2009 21:07:14 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so472651eyd.51 for ; Wed, 11 Nov 2009 21:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=7xM0hfG7jU1dSafblzxxxnMeWwHrUvminPHwIILFGfI=; b=tgkuZEH+UpkVSyQxUBK04qUcUfIuGeXp2rQObtEEcD5FtX3+CNRyhnoPV7GF5x/uem /uXv9yfOJxglFpgxGdxvXokvIxu+6mJmqoRiHwkMZ/uoLCE45L+yn4U27IKr1eDMJ+Pu Dcwvjq/STCQy7m4fvrSyUtDIsQraE2taMYnhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=MNWnjeGufl/nWHKIArKgx7jmfmm7n+GRMhN7sKiTAQlqaK2Fhz+n8B8Jb8boeYGbyt zOcPSqqplBVcCUhIdPSEq+sPL5Jsq4VKUAw20X7MOJ38J0Cvyuz806ttTuR0XUHx5F0Q YwGznlITNj4Q2nQF1mk/4L7W4PT+mMYQpgNrk= Received: by 10.213.2.71 with SMTP id 7mr7084244ebi.88.1258002459672; Wed, 11 Nov 2009 21:07:39 -0800 (PST) Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 10sm2256474eyd.47.2009.11.11.21.07.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 21:07:39 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFB980F.7050105@jacaranda.org> Date: Thu, 12 Nov 2009 05:07:27 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <20091111121708.EF62069EDB2@kilo.networkresonance.com> In-Reply-To: <20091111121708.EF62069EDB2@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFC6D41FE075A87423CFB2CFC" Subject: Re: [TLS] Comments on draft-solinas-tls-additional-prf-input X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 05:07:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFC6D41FE075A87423CFB2CFC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > Despite not being clear on what this is for, I don't have a problem > with there being a code point assigned for this extension for USG use. = > However, I don't think that some of the proposed uses are in > fact appropriate and would like to see the document revised accordingly= =2E >=20 > In particular, there are two potential things one might be trying > to do here: >=20 > 1. Add additional randomness into the PRF. > 2. Add structured, meaningful data into the PRF. >=20 > AFAICT, the first of these is useless but harmless: useless because > the security guarantees of TLS require only uniqueness of the=20 > Random values, not unpredictability, and 28 bytes is far more than > required to provide a statistical guaranteee of uniqueness; harmless > because the PRF can easily absorb additional new data, even if it > is completely nonrandom.=20 >=20 > The second, however, is a backdoor method of extending TLS and the > semantics are completely different: in order to be useful, the > data in the extension must be processed and potentially checked > by the other side. Several mechanisms for extending TLS already > exist (TLS Extensions and then the TLS Supplemental Data > message) and should not add yet another generic mechanism=20 > here. [...] > The mechanism described here has several desirable features which ma= y > prove useful beyond the requirements of the US Government > applications. It is easy to implement, and using it adds little to > the overall computation of the TLS handshake. Further, > interoperability is preserved between clients that implement the > extension and servers that do not, and between clients that do not > implement the extension and servers that do. >=20 > These really aren't generically desirable features, since they > just say "this doesn't do any damage". I guess that's desirable, > but the relevant question is why one would want to do this at all. I agree. The gist of any discussion of rationale seems to be basically: "The U.S. Government has these special requirements that you wouldn't understand. Since they're a government, they needn't explain themselves, and we're not going to explain either." One possible reason why you might want to cause a handshake failure for clients and servers that fail to agree on the 'additional input', is to avoid cross-protocol attacks, i.e. to prevent a session that is supposed to be using one protocol from being misinterpreted as using another. I'm not convinced that this extension is the simplest or most effective way of doing that, though. In the descriptions of 'OtherInfo' in , it seems that one intended usage is to prevent confusion about which identities are participating in the key exchange (for example "At a minimum, PartyUInfo shall include ID_U, the identifier of party U.", on PDF page 46). In TLS that's unnecessary because any certificates are included in the Finished hashes. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFC6D41FE075A87423CFB2CFC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr7mBYACgkQWUc8YzyzqAfOxwD8CPYcPukyiOi8fN2xMPFExDfC y3Fw0vNAHoi9qvlYY8MA/AiA6rIpFu/14Zcqw9yQ8vAiy3pkmkdUoxjOLwDfQlOW =PRKc -----END PGP SIGNATURE----- --------------enigFC6D41FE075A87423CFB2CFC-- From mrex@sap.com Wed Nov 11 21:12:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6FD3A6B9D for ; Wed, 11 Nov 2009 21:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.092, 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 tcXBqtO0Rv49 for ; Wed, 11 Nov 2009 21:12:20 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E7C0A3A6B87 for ; Wed, 11 Nov 2009 21:12:19 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAC5Cjsf006673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 06:12:45 +0100 (MET) From: Martin Rex Message-Id: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 12 Nov 2009 06:12:44 +0100 (MET) In-Reply-To: <4AFB21E8.7040609@extendedsubset.com> from "Marsh Ray" at Nov 11, 9 02:43:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 05:12:21 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > I think you might be barking up the wrong tree. > > > > This MITM-susceptibility is _not_ a problem specific to SSLv3. > > It is a problem that affects the entire installed base of > > TLS v1.0, TLS v1.1 and TLS v1.2 in _exactly_ the same fashion. > > Yes, but TLS >= 1.0 can be fixed properly with > https://datatracker.ietf.org/drafts/draft-rescorla-tls-renegotiation/ There is nothing in that draft that prevents its use for SSLv3 > > > As far as upgrading/fixing is concerned: I do _not_ see an issue > > the SSLv3 spec that would prevent the proposed fix to be used > > even for sessions negotiated with protocol version 0x03,0x00. > > SSL 3.0 doesn't seem to allow extensions on Server and Client Hello > messages. That is wrong. The SSLv3 spec has the exact same provisions for TLS extensions as the TLSv1.0 and TLSv1.1 specs. TLS extensions became a standard part of the protocol in TLSv1.2 only. Compare the specs and you will see. > > > The issue of interoperability with that installed base seems to > > have been sufficiently severe, that at least one Browser vendor > > decided to implement a re-connect retry logic with a fallback > > to extension-free SSLv3 ClientHello. > > Maybe that was one of those "we've always done it that way" decisions > that needs to be revisited. Breaking installed base just for the sake of the fun of it sounds like a pretty bad idea. > > The proposed draft-rescorla-tls-renegotiation "RI extension" provides a > solution which restores the security of connections where both endpoints > implement it. > There is probably no way to restore that security without patching both > endpoints. This is a misrepresentation. There is _NO_ known security problem with a full TLS handshake if _no_ renegotiation is performed. I'm perfectly OK with fixing TLS to provide a secure basis for the previously flawed assumptions of several servers, provided that all servers that want to use renegotiation in the future are updated. I have a very significant problem with any recommendation, let alone a requirement to brick perfectly valid and secure installed base that does not contain this TLS enhancement, but also doesn't contain renegotiation and there is not vulnerable. Especially since this is completely unnecessary! > > > Servers performing a traditional SSL handshake is _not_ a security > > problem. > > There are some attacks in which the client sees the renegotiation and > the server only sees one connection. So what? The vulnerability is only an entirely with the part that performs the insecure renegotiation. The reliable fix (without upgrade) is to disable renegotiation of that component. > > > Doing the secure renegotiation through the TLS extension in an > > official renegotiation is not the problem. Fixing means that the > > code will have to be changed. If the change is sufficiently small, > > it can be added with a relative small amount of work to servers > > at all protocol levels, including SSLv3. > > So SSLv3 would be retroactively given hello extensions? Sounds like a > breaking change. Wouldn't it be easier to just use TLS? Huh? SSLv3 is perfectly OK with hello extensions. Btw., quite a lot of sessions established with protocol version SSLv3 (0x03,0x00) might actually be between implementations of TLS that just use conservative defaults because they don't have a reconnect fallback to and extension-less SSLv3 handshake. It would be good to stop confusing people. Adding TLS support to an existing SSLv3 implementation is >5x the work than adding the proposed TLS extension RI. And you're still just as vulnerable. What we need is that the installed base out there needs to discontinue using the insecure renegotiation with TLS. JUST THAT. This means either adding the TLS extension RI or reliably disable renegotiation. Please every stop suggesting upgraded to TLS v1.something. That will cause more harm than good, because it gives a completely wrong impression about what needs to be done. I'm fine with requiring a proper TLS extension in the renegotiation(!) handshake to transfer the verify_data of the finished messages. It's clean and still very simple, and fits SSLv3 just as nicely as it does TLSv1.0. This may even help to make SSLv3 implementations to improve their SSLv3 spec compliance and interop with clients proposing TLS extensions. There may be lots of good reasons why upgrading or completely replacing an implementation of SSLv3 is simply not an option, but adding the TLS extension RI is. -Martin From mrex@sap.com Wed Nov 11 21:37:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3DB3A6B82 for ; Wed, 11 Nov 2009 21:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 EC8tWZB-AyGS for ; Wed, 11 Nov 2009 21:37:02 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2C9193A6A0B for ; Wed, 11 Nov 2009 21:37:02 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAC5bTXI025008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 06:37:29 +0100 (MET) From: Martin Rex Message-Id: <200911120537.nAC5bQV0021407@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 12 Nov 2009 06:37:26 +0100 (MET) In-Reply-To: <4AF51527.5060404@jacaranda.org> from "David-Sarah Hopwood" at Nov 7, 9 06:35:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 05:37:03 -0000 The quoted sections are obvious defects in that documents. rfc5246 7.4.1.4 (top of page 45) seems to contain a corrected version: In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption. Most current TLS extensions are relevant only when a session is initiated: when an older session is resumed, the server does not process these extensions in Client Hello, and does not include them in Server Hello. However, some extensions may specify different behavior during session resumption. what TLS documentations should have expressed (what it meant) is that TLS extensions ought to not modify the cryptographic properties of the resumed session. The TLS RI extension will not modify the cryptographic properties of the resumed session. -Martin David-Sarah Hopwood wrote: > > David-Sarah Hopwood wrote: > > Comments on > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > > > > Overall I think this draft is a good solution to the identified security > > problem. > > > > The draft defines an extension that affects renegotiation, which might > > be perceived to conflict with RFC 3546 section 2.3: > > Ah, I should have been referencing RFC 4366 section 3 -- but the > wording is almost the same: > > Note also that all the extensions defined in this section are > relevant only when a session is initiated. When a client includes > one or more of the defined extension types in an extended client > hello while requesting session resumption: > > - If the resumption request is denied, the use of the extensions is > negotiated as normal. > > - If, on the other hand, the older session is resumed, then the > server MUST ignore the extensions and send a server hello > containing none of the extension types. In this case, the > functionality of these extensions negotiated during the original > session initiation is applied to the resumed session. > > and the same comments apply. > > -- > David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com > > > --------------enig78606FA1DFD4566081965DA6 > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iF4EAREIAAYFAkr1FTAACgkQWUc8YzyzqAeXzQD/cAwn2+qxFM7S/DwRcg+bFLf0 > 5tm2hOBIsJwrCA233twBAIBGJi0NscO0nM5PZK+Pobm+oFnotOOkxRSx+4syl0v/ > =IaTm > -----END PGP SIGNATURE----- > > --------------enig78606FA1DFD4566081965DA6-- > > --===============1151963907== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --===============1151963907==-- > From ekr@networkresonance.com Wed Nov 11 21:57:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755AF3A69A0 for ; Wed, 11 Nov 2009 21:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-Me+tLMI67o for ; Wed, 11 Nov 2009 21:57:46 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id A3D363A6980 for ; Wed, 11 Nov 2009 21:57:46 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N8ShD-0003jO-00 for tls@ietf.org; Thu, 12 Nov 2009 07:58:15 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 58D2369EF16; Thu, 12 Nov 2009 07:59:10 +0200 (EET) Date: Thu, 12 Nov 2009 07:59:09 +0200 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4AF99E04.3060604@pobox.com> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091112055910.58D2369EF16@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 05:57:47 -0000 At Tue, 10 Nov 2009 09:08:20 -0800, Michael D'Errico wrote: > A client that wants protection from this attack MUST send the extension > in its initial handshake. Why don't you want to do that? > > The attack being discussed happens on the client's *initial* handshake. > The server sees it as a renegotiation, so the client needs to be able to > tell the server that it thinks it is performing an initial handshake. > That is exactly what this extension provides. If you don't send the > extension on an initial handshake you are risking being attacked. I don't see that that's the case: you're risking being attacked in any case if the server is not upgraded. > All servers SHOULD disable renegotiation to protect clients, but it's > been said that this is impractical. A server may be configured to allow > renegotiation even though it understands the new extension. Thus by not > sending the extension in your initial handshake, you are just as > vulnerable, even though you could have prevented an attack. I don't really agree with this: servers which allow renegotiation without this extension are unwise. -Ekr From ekr@networkresonance.com Wed Nov 11 22:07:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F5C3A69DD for ; Wed, 11 Nov 2009 22:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.095 X-Spam-Level: X-Spam-Status: No, score=0.095 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey+hO2fgYIRC for ; Wed, 11 Nov 2009 22:07:43 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 276603A69CC for ; Wed, 11 Nov 2009 22:07:43 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N8Sqp-0007x8-00 for tls@ietf.org; Thu, 12 Nov 2009 08:08:11 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 09F3169EF21; Thu, 12 Nov 2009 08:09:07 +0200 (EET) Date: Thu, 12 Nov 2009 08:09:06 +0200 From: Eric Rescorla To: Dr Stephen Henson In-Reply-To: <4AFB0995.8060504@drh-consultancy.demon.co.uk> References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> <4AF83FB9.9060302@drh-consultancy.demon.co.uk> <20091109175954.8DF8F69E5CB@kilo.networkresonance.com> <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com> <4AFB0995.8060504@drh-consultancy.demon.co.uk> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091112060907.09F3169EF21@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 06:07:44 -0000 At Wed, 11 Nov 2009 18:59:33 +0000, Dr Stephen Henson wrote: > > Pasi.Eronen@nokia.com wrote: > > Eric Rescorla wrote: > > > >> I don't think the problem here is really the code point assignment. > >> > >> I would imagine the IESG and IANA to be pretty good about doing > >> advance assignments once the WG has converged on the exact contents > >> of the extension. I know we had pretty good consensus within a > >> smaller group, but if when we run it by some cryptographers they say > >> it's insecure we'll need to change it, at which point it won't > >> really help to have deployed code with the "early" code point. > > > > > > > > I think this is one of those cases where an exception to the usual > > procedures might be in order, but the "once the WG has converged on > > the exact contents" is an important point here. It's relatively rare > > that the -00 version of some internet draft and the final RFC are > > actually interoperable. > > > > Using the same extension number for multiple incompatible versions of > > the draft is probably not a good idea (and probably not very secure, > > either -- if the handshake fails, you don't know if it's due to an > > attack or just interoperability problem, and the latter might be much > > more likely), and I'd like to avoid allocating multiple extension > > numbers for different versions of the draft, too. > > > > Would including a version number in the extension help? Then if the format does > change implementations can indicate that it is a version they don't support or > decide they are willing to support an older version. > > This would also cover the case where some cryptographic attack is found against > the current form later. We keep the extension number but bump up the version. I considered that, but I'm not sure it really helps. Once the initial version is widely supported you need to send the old version as well as the new version for a smooth transition. Might as well have two extension code points. -Ekr From ekr@networkresonance.com Wed Nov 11 22:15:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40563A6A4D for ; Wed, 11 Nov 2009 22:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvUMUBeu6ulF for ; Wed, 11 Nov 2009 22:15:18 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 3A7663A67A3 for ; Wed, 11 Nov 2009 22:15:15 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N8Sy5-0002nz-00 for tls@ietf.org; Thu, 12 Nov 2009 08:15:41 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id DFC7169EF22; Thu, 12 Nov 2009 08:16:36 +0200 (EET) Date: Thu, 12 Nov 2009 08:16:36 +0200 From: Eric Rescorla To: Nelson B Bolyard In-Reply-To: <4AFB728C.9050102@bolyard.me> References: <4AFB64FA.1060505@bolyard.me> <4AFB728C.9050102@bolyard.me> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091112061636.DFC7169EF22@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 06:15:29 -0000 At Wed, 11 Nov 2009 18:27:24 -0800, Nelson B Bolyard wrote: > > On 2009-11-11 17:48 PDT, Wan-Teh Chang wrote: > > On Wed, Nov 11, 2009 at 5:29 PM, Nelson B Bolyard wrote: > >> At least Two implementers have read the draft differently and implemented > >> non-interoperable implementations. The draft needs clarification. > >> > >> First the draft says: > >> > >> The "extension data" field of this extension contains a > >> "Renegotiation_Info" structure: > >> > >> struct { > >> opaque renegotiated_connection<0..255>; > >> } Renegotiation_Info; > >> > >> Then it says: > >> > >> The contents of this extension are specified as follows. > >> > >> o If this is the initial handshake for a connection, then this field > >> is of zero length in both the ClientHello and the ServerHello. > >> > >> One implementer interprets this to mean that the extension data field > >> is of zero length. Another interprets it to mean that the > >> "renegotiated_connection" field inside the Renegotiation_Info is to > >> have zero length. This leads to two different encodings, which are: > >> > >> FF 01 00 00 > >> > >> FF 01 00 01 00 > >> > >> I suggest replacing "the contents of this extension" with either > >> "The contents of the renegotiated_connection", or > >> "the contents of the extension data field", to make this sufficiently > >> explicit. > > > > This kind of ambiguity was also in the original RFC 4507 for > > the TLS session ticket extension, and had to be addressed in > > a new RFC 5077. See RFC 5077 section 1 and appendix A. > > Thanks for the tip, Wan-Teh. So, summarizing that appendix, it says that > clients have two different interpretations of an empty session ticket > extension, so servers should accept either one and should return an > empty extension in the same format as that sent by the client. > > Fellow TLS WG members, > Let's not repeat that for this extension. This extension hasn't been > published in an RFC yet, so let's nip this in the bud, and make it > completely unambiguous before that happens. I agree. I'll put it on my TODO list to fix this. IMHO, the better interpretation is an empty vector (i.e. 00) for the data field with an extension containing only that. I.e. ff 01 00 01 00 -Ekr From bmoeller@acm.org Wed Nov 11 22:15:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C899128C139 for ; Wed, 11 Nov 2009 22:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Jpmh49gsJh3u for ; Wed, 11 Nov 2009 22:15:29 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 4CA7B3A6A20 for ; Wed, 11 Nov 2009 22:15:21 -0800 (PST) Received: from [172.19.233.94] ([216.239.45.130]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MHci0-1N7MVG2Z2K-003mwq; Thu, 12 Nov 2009 07:15:44 +0100 From: Bodo Moeller To: Eric Rescorla In-Reply-To: References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 22:15:39 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX18y8pmtzVTHhK/ICZ7NTljYBTpcfG0fg/8OObB rOal2H4TN9Tfi7hs4TqTervqPACo4VughXcvMj+m7vy7jNrvLf zPq97KDaebZiYBctWTl1w== Cc: "tls@ietf.org" Subject: Re: [TLS] TLS renegotiation issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 06:15:54 -0000 On Nov 5, 2009, at 10:16 AM, Eric Rescorla wrote: > I now have a draft extension up at: > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml [= http://www.ietf.org/id/draft-rescorla-tls-renegotiation-00.txt] There's pointless overhead in the following extract: Sending the client's verify_data to the server for verification makes sense; sending the server's verify_data to the client for verification makes less sense, but still sense; sending another copy of the client's verify_data to the client, however, doesn't make sense. Using symmetric 12-byte values, where each party sends its own previous verify_data, achieves the same with fewer bytes. Bodo struct { opaque renegotiated_connection<0..255>; } Renegotiation_Info; All TLS implementations SHOULD support this extension. TLS clients SHOULD generate it with every handshake and TLS servers SHOULD generate it in response to any client which offers it. The contents of this extension are specified as follows. o If this is the initial handshake for a connection, then this field is of zero length in both the ClientHello and the ServerHello. o For ClientHellos which are renegotiating, this field contains the verify_data from the Finished message sent by the client on the immediately previous handshake. For current versions of TLS, this will be a 12-byte value. Note that this value is the "tls- unique" channel binding from [I-D.altman-tls-channel-bindings] o For ServerHellos which are renegotiating, this field contains the concatenation of the verify_data values sent by the client and the server (in that order) on the immediately previous handshake. For current versions of TLS, this will be a 24-byte value. From marsh@extendedsubset.com Wed Nov 11 23:49:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73ADF3A686D for ; Wed, 11 Nov 2009 23:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 NEN-1U94KA12 for ; Wed, 11 Nov 2009 23:49:49 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 67CC73A69DA for ; Wed, 11 Nov 2009 23:49:49 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N8URd-000GgI-Pg; Thu, 12 Nov 2009 07:50:17 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id EBBBF6678; Thu, 12 Nov 2009 07:50:15 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+WMYlfsRZ20GUized/Hs5v/hPoWbMfQoU= Message-ID: <4AFBBE35.4010306@extendedsubset.com> Date: Thu, 12 Nov 2009 01:50:13 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" , Martin Rex References: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp> In-Reply-To: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 07:49:50 -0000 Martin Rex wrote: > That is wrong. The SSLv3 spec has the exact same provisions for > TLS extensions as the TLSv1.0 and TLSv1.1 specs. > > TLS extensions became a standard part of the protocol in TLSv1.2 only. > > Compare the specs and you will see. Very enlightening, it's even more complicated than you said. No wonder these things don't interoperate quite so well. Here's what I find: SSL 3.0 draft-freier-ssl-version3-02.txt "In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods." RFC 2246 TLS 1.0 (Jan 1999) "In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message must match the description of the message precisely." RFC 3546 TLS Extensions (June 2003) Updates 2246 (TLS 1.0) "The extensions described in this document may be used by TLS 1.0 clients and TLS 1.0 servers. The extensions are designed to be backwards compatible - meaning that TLS 1.0 clients that support the extensions can talk to TLS 1.0 servers that do not support the extensions, and vice versa." "Note that the extended server hello message is only sent in response to an extended client hello message. This prevents the possibility that the extended server hello message could "break" existing TLS 1.0 clients" "The extended server hello message format MAY be sent in place of the server hello message when the client has requested extended functionality via the extended client hello message" RFC 4346 TLS 1.1 (April 2006) "In the interests of forward compatibility, it is permitted that a client hello message include extra data after the compression methods. This data MUST be included in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message MUST match the description of the message precisely. RFC 4366 TLS Extensions (April 2006) Updates 4346 (TLS 1.1) "The document therefore updates TLS 1.0 [TLS] and TLS 1.1" "The extended server hello message format MAY be sent in place of the server hello message when the client has requested extended functionality via the extended client hello message" RFC 5246 TLS 1.2 "Clients MAY request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 7.4.1.4." "[server] A list of extensions. Note that only extensions offered by the client can appear in the server's list." ------ My interpretation: SSL 3.0 Allows room at the end of Client Hello for extra data. Is silent on extra data after Server Hello. No standard defines anything to be passed here. TLS 1.0 Allows room at the end of Client Hello for extra data Forbids extra data after Server Hello. Possibly went four years with no extensions defined, so early implementations were untested in this. June 2003 RFC 3546 Uses room defined in TLS 1.0 to grow ClientHello into ExtendedClientHello. Defines a new ExtendedServerHello message without assigning it a new HandshakeType. This is probably OK. SSL proxying and monitoring may have been confused by this contradiction of the spec with no version number bump. TLS 1.1 Reiterates that only ClientHello can have extra data. No provision for ExtendedServerHello. RFC 4366 Updates TLS 1.0 and 1.1 to re-allow extensions. This was simultaneous to 1.1 spec, so just an update. TLS 1.2 Defines extensions as part of the main TLS spec. ------ Conclusions: Nothing defines extensions for SSL 3.0, how such servers will react when sent extra ClientHello data is somewhat unpredictable. Perfectly-conforming implmentations since spec of Jan 1999 should, in theory, not be broken. In practice, TLS server implementations designed before about 2004 probably had no compliant clients with which to test that would send any data after the traditional ClientHello. Such systems probably shipped for quite some time afterwards. For example, all pre-Vista Windows OS's may be in this category based on design date. There are a large number of TLS implementations that are not currently extension-aware which will have to retrofit at least primitive support in order to benefit from this security fix. - Marsh From noskov@microsoft.com Wed Nov 11 23:54:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149883A6919 for ; Wed, 11 Nov 2009 23:54:27 -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 CKqc6PZFhF4T for ; Wed, 11 Nov 2009 23:54:26 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 74C3F3A68FA for ; Wed, 11 Nov 2009 23:54:26 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 Nov 2009 23:54:55 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server id 14.0.639.20; Wed, 11 Nov 2009 23:54:55 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 11 Nov 2009 23:54:55 -0800 From: Nasko Oskov To: "tls@ietf.org" Thread-Topic: [TLS] renegotiation draft needs clarification !! Thread-Index: AQHKYzdxJQvjwrCuIEim8qy91YCQnZEyNCAAgAAK4wCAABYCAP//vnhQ Date: Thu, 12 Nov 2009 07:52:38 +0000 Deferred-Delivery: Thu, 12 Nov 2009 07:53:00 +0000 Message-ID: References: <4AFB64FA.1060505@bolyard.me> <4AFB728C.9050102@bolyard.me> <4AFB8502.60102@pobox.com> In-Reply-To: <4AFB8502.60102@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 12 Nov 2009 00:22:28 -0800 Subject: Re: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 08:02:09 -0000 >>>> This leads to two different encodings, which are: >>>> >>>> FF 01 00 00 >>>> >>>> FF 01 00 01 00 > >I will selfishly vote for the second choice since that is >how I implemented it, though it would be easy to change. I interpreted it the same way, as an empty vector. Thanks,=09 Nasko From mickgray@au1.ibm.com Thu Nov 12 00:35:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9543A67B0 for ; Thu, 12 Nov 2009 00:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 OBh7Qyo9QjTp for ; Thu, 12 Nov 2009 00:35:56 -0800 (PST) Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147]) by core3.amsl.com (Postfix) with ESMTP id BB2ED3A68F5 for ; Thu, 12 Nov 2009 00:35:55 -0800 (PST) Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp05.au.ibm.com (8.14.3/8.13.1) with ESMTP id nAC8XRX5010761 for ; Thu, 12 Nov 2009 19:33:27 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nAC8aMBr1806472 for ; Thu, 12 Nov 2009 19:36:22 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nAC8aMTu001777 for ; Thu, 12 Nov 2009 19:36:22 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nAC8aMpq001774 for ; Thu, 12 Nov 2009 19:36:22 +1100 In-Reply-To: To: Nasko Oskov X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Thu, 12 Nov 2009 18:36:06 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 12/11/2009 19:43:00 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "tls@ietf.org" Subject: Re: [TLS] renegotiation draft needs clarification !! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 08:35:56 -0000 > >>>> This leads to two different encodings, which are: > >>>> > >>>> FF 01 00 00 > >>>> > >>>> FF 01 00 01 00 > > > >I will selfishly vote for the second choice since that is > >how I implemented it, though it would be easy to change. > > I interpreted it the same way, as an empty vector. > Thanks, > Nasko Same here Mick > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Thu Nov 12 06:00:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DAF93A6AB5 for ; Thu, 12 Nov 2009 06:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 CdxW+1hM-pmb for ; Thu, 12 Nov 2009 06:00:44 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 140AA3A6A70 for ; Thu, 12 Nov 2009 06:00:43 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nACE1AwD018921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 15:01:10 +0100 (MET) From: Martin Rex Message-Id: <200911121401.nACE16Au020982@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 12 Nov 2009 15:01:06 +0100 (MET) In-Reply-To: <4AFBBE35.4010306@extendedsubset.com> from "Marsh Ray" at Nov 12, 9 01:50:13 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 14:00:45 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > That is wrong. The SSLv3 spec has the exact same provisions for > > TLS extensions as the TLSv1.0 and TLSv1.1 specs. > > > > TLS extensions became a standard part of the protocol in TLSv1.2 only. > > > > Compare the specs and you will see. > > Very enlightening, it's even more complicated than you said. No wonder > these things don't interoperate quite so well. > > Here's what I find: > > SSL 3.0 draft-freier-ssl-version3-02.txt > > "In the interests of forward compatibility, it is > permitted for a client hello message to include > extra data after the compression methods." I would suggest the following document for SSLv3 from 18-Nov-1996: http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. > > RFC 2246 TLS 1.0 (Jan 1999) > > "In the interests of forward compatibility, it is permitted for a > client hello message to include extra data after the compression > methods. This data must be included in the handshake hashes, but > must otherwise be ignored. This is the only handshake message for > which this is legal; for all other messages, the amount of data > in the message must match the description of the message precisely." > > RFC 3546 TLS Extensions (June 2003) > Updates 2246 (TLS 1.0) > > "The extensions described in this document may be used by TLS 1.0 > clients and TLS 1.0 servers. The extensions are designed to be > backwards compatible - meaning that TLS 1.0 clients that support the > extensions can talk to TLS 1.0 servers that do not support the > extensions, and vice versa." > "Note that the extended server hello message is only sent in response > to an extended client hello message. This prevents the possibility > that the extended server hello message could "break" existing TLS 1.0 > clients" > "The extended server hello message format MAY be sent in place of the > server hello message when the client has requested extended > functionality via the extended client hello message" > > RFC 4346 TLS 1.1 (April 2006) > > "In the interests of forward > compatibility, it is permitted that a client hello message include > extra data after the compression methods. This data MUST be included > in the handshake hashes, but must otherwise be ignored. This is the > only handshake message for which this is legal; for all other > messages, the amount of data in the message MUST match the > description of the message precisely. > > RFC 4366 TLS Extensions (April 2006) > Updates 4346 (TLS 1.1) > "The document therefore updates TLS 1.0 [TLS] and TLS 1.1" > "The extended server hello message format MAY be sent in place of the > server hello message when the client has requested extended > functionality via the extended client hello message" > > RFC 5246 TLS 1.2 > > "Clients MAY request extended functionality from servers by sending > data in the extensions field. The actual "Extension" format is > defined in Section 7.4.1.4." > "[server] A list of extensions. Note that only extensions offered > by the client can appear in the server's list." > > ------ > My interpretation: > > SSL 3.0 Allows room at the end of Client Hello for extra data. > Is silent on extra data after Server Hello. > No standard defines anything to be passed here. > > TLS 1.0 Allows room at the end of Client Hello for extra data > Forbids extra data after Server Hello. > Possibly went four years with no extensions defined, > so early implementations were untested in this. > > June 2003 > > RFC 3546 Uses room defined in TLS 1.0 to grow ClientHello into > ExtendedClientHello. > Defines a new ExtendedServerHello message without assigning > it a new HandshakeType. This is probably OK. SSL proxying > and monitoring may have been confused by this contradiction > of the spec with no version number bump. > > TLS 1.1 Reiterates that only ClientHello can have extra data. > No provision for ExtendedServerHello. > > RFC 4366 Updates TLS 1.0 and 1.1 to re-allow extensions. > This was simultaneous to 1.1 spec, so just an update. > > TLS 1.2 Defines extensions as part of the main TLS spec. > > ------ > Conclusions: > > Nothing defines extensions for SSL 3.0, how such servers will react when > sent extra ClientHello data is somewhat unpredictable. > > Perfectly-conforming implmentations since spec of Jan 1999 should, in > theory, not be broken. > > In practice, TLS server implementations designed before about 2004 > probably had no compliant clients with which to test that would send any > data after the traditional ClientHello. Such systems probably shipped > for quite some time afterwards. For example, all pre-Vista Windows OS's > may be in this category based on design date. > > There are a large number of TLS implementations that are not currently > extension-aware which will have to retrofit at least primitive support > in order to benefit from this security fix. I think it is OK to encourage interoperability with ExtendenClientHello and ExtendendServerHello in order to implement Eric's proposal for the TLS extension Renegotiation_Info. ClientHello extensibility has been in the spec for very long, and really is not that much to implement. I would appreciate if Eric's draft would precisely describe what exact elements of TLS extension (rfc4366 or what got integrated into rfc5246) is necessary to implement this draft. (ExtendenClientHello, ExtendendServerHello, correct hashing of handshake message, creation and parsing of extension_data). -Martin From mike-list@pobox.com Thu Nov 12 09:31:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3333A6ACD for ; Thu, 12 Nov 2009 09:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 2SC3+zM-jamQ for ; Thu, 12 Nov 2009 09:31:51 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 5A67F3A6AC2 for ; Thu, 12 Nov 2009 09:31:50 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id CEE8B7EDAC for ; Thu, 12 Nov 2009 12:32:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=pwPVVUJZXBDV UrXZhAMMKbwFRoI=; b=J3f8Cy27MQkdyM3v3JSyWj5OR0jXaju6iWHOwG09YoDR CQJEjvGWzPqwxYY2nf/INl3DpNkaVdAWRxHGn7ewRakZJ5GI7U5rX0GQJfHb/k2l JrlLUxu+Ne5alQ2aro+ia89W4wE0ioN2DE1Al2mhh2/sIFzXGZhIhulxHXsKoEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=fEhdz6 4aGJ0kChYFpxh0Q8GR+BcNSbfpT2SE3CSHSaqAwQd9zJgfHN6p6E65yRCURlj+nz 2TfQDO4PNVoSPC3rpYmNfx/t4Xps7/XPXttvQkPS1AgOwmYGYbfs9UoSnLcWyfx0 IKPaTr/s2TYXDymVkAijhwouKwJ4jjhG6h6xg= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B52617EDAB for ; Thu, 12 Nov 2009 12:32:18 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 270CD7EDAA for ; Thu, 12 Nov 2009 12:32:17 -0500 (EST) Message-ID: <4AFC46D8.9050905@pobox.com> Date: Thu, 12 Nov 2009 09:33:12 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> In-Reply-To: <20091112055910.58D2369EF16@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 53A31CD6-CFB1-11DE-A875-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 17:31:52 -0000 Eric Rescorla wrote: > At Tue, 10 Nov 2009 09:08:20 -0800, > Michael D'Errico wrote: >> A client that wants protection from this attack MUST send the extension >> in its initial handshake. Why don't you want to do that? >> >> The attack being discussed happens on the client's *initial* handshake. >> The server sees it as a renegotiation, so the client needs to be able to >> tell the server that it thinks it is performing an initial handshake. >> That is exactly what this extension provides. If you don't send the >> extension on an initial handshake you are risking being attacked. > > I don't see that that's the case: you're risking being attacked in > any case if the server is not upgraded. My point was that if the server *is* upgraded and the client does not send the extension on its initial handshake, it is taking an unnecessary risk. It is relying on the server to not continue with an insecure renegotiation. While this is the recommended advice, it might not be followed for practical reasons (as others have pointed out). Therefore, the client has just shot itself in the foot -- it had the knowledge of how to avoid the attack but didn't use it. >> All servers SHOULD disable renegotiation to protect clients, but it's >> been said that this is impractical. A server may be configured to allow >> renegotiation even though it understands the new extension. Thus by not >> sending the extension in your initial handshake, you are just as >> vulnerable, even though you could have prevented an attack. > > I don't really agree with this: servers which allow renegotiation without > this extension are unwise. Right, but it will take a (long?) while before everybody can behave according to the recommendations. Mike From marsh@extendedsubset.com Thu Nov 12 10:30:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB85F28C134 for ; Thu, 12 Nov 2009 10:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 G6WIvIjPDdDa for ; Thu, 12 Nov 2009 10:30:28 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 39E7F28C144 for ; Thu, 12 Nov 2009 10:30:28 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N8eRd-000MDt-24 for tls@ietf.org; Thu, 12 Nov 2009 18:30:57 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2256B6678 for ; Thu, 12 Nov 2009 18:30:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19tUqtoEX14yPOl5kiN/AIL8NgQFOc0MR4= Message-ID: <4AFC545F.100@extendedsubset.com> Date: Thu, 12 Nov 2009 12:30:55 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> In-Reply-To: <4AFC46D8.9050905@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 18:30:29 -0000 Michael D'Errico wrote: > > Right, but it will take a (long?) while before everybody can behave > according to the recommendations. The primary factor is not how long it takes for "everybody" to update. Maybe that never happens. What matters is more that there is a significant set of clients and servers in the world that _will_ gain the protections of the fix because their users and admins are conscientious and will update quickly when the patch is available. - Marsh From Nicolas.Williams@sun.com Thu Nov 12 10:37:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69E53A6AF3 for ; Thu, 12 Nov 2009 10:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, 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 yv4QzyXYVbih for ; Thu, 12 Nov 2009 10:37:20 -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 A76CF3A6AF2 for ; Thu, 12 Nov 2009 10:37:20 -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 nACIbnEX003617 for ; Thu, 12 Nov 2009 18:37:49 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 nACIbnk5003483 for ; Thu, 12 Nov 2009 11:37:49 -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 nACIIj6r018401; Thu, 12 Nov 2009 12:18:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACIIjt4018400; Thu, 12 Nov 2009 12:18:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 12:18:45 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091112181844.GE1105@Sun.COM> References: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp> <4AFBBE35.4010306@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFBBE35.4010306@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 18:37:21 -0000 On Thu, Nov 12, 2009 at 01:50:13AM -0600, Marsh Ray wrote: > Martin Rex wrote: > > That is wrong. The SSLv3 spec has the exact same provisions for > > TLS extensions as the TLSv1.0 and TLSv1.1 specs. > > > > TLS extensions became a standard part of the protocol in TLSv1.2 only. > > > > Compare the specs and you will see. > > Very enlightening, it's even more complicated than you said. No wonder > these things don't interoperate quite so well. > > Here's what I find: Indeed. And I should add that the re-negotiation channel binding can be achieved _without_ ServerHello extensions! If that means improved odds for interop, then you should consider it. How? Here's two options: Option 1: All-or-nothing binding (no support negotiation) - The client sends a ClientHello extension saying it _will_ add the outer connection's client Finished message to the inner connection's Finished message PRF inputs, but the extension does not include that data; - The server either knows the extension or doesn't: - If the server knows the extension, it will modify its Finished message computations in the same way as the client, and if both have the same outer connection's client Finished message at hand, then the handshake will succeed, else it will fail (i.e., the inner connection's Finished messages will not check out); - If the server does NOT know the extension then it will proceed as usual and so... will fail to verify the client's Finished message, and the client will fail to verify server's Finished message. Option 2: Secure negotiation (client can securely detect if the server supports binding, and can choose to forego channel binding if the server doesn't) - The client sends a ClientHello extension that includes the outer connection's client Finished message; - The client will add the outer connection's server Finished message to the inner connection's _server_ Finished message PRF inputs (but not to the inner connection's _client_ Finished message PRF inputs); - The server either knows the extension or doesn't: - If the server knows the extension, it will modify its Finished message computations in the same way as the client, and if both have the same outer connection's server Finished message at hand, then the handshake will succeed, else it will fail (i.e., the inner connection's Finished messages will not check out); - If the server does NOT know the extension then it will proceed as usual and so... will fail to verify the client's Finished message, and the client will fail to verify server's Finished message. Note that in either case the ClientHello extension is "non-critical" (in one sense), there's no ServerHello extension, but the client reliably finds out if the server understood the extension. There's no reflection attack. The server cannot be implemented incorrectly (that is, it can't parrot something the client sent). In option (2) the client gets to reliably discover whether the server supports the extension, but in a way such that the only way that an MITM can fool the client is if the negotiated cipher suite does not authenticate the server (if a server cert is used, then the MITM is out unless the MITM has the private keys to that cert). But even if such a cipher suite had been negotiated, the MITM cannot leverage the client's user cert authentication to authenticate to the server. In neither option can the MITM get away with stripping the extension from the client's Hello, nor can the MITM cause the outer connection's channel bindings data to match on the client and server side. The nice thing here is that option (2) could be implemented even by SSLv3 clients and servers (supposing anyone would bother to patch those). Nico -- From n.mavrogiannopoulos@gmail.com Thu Nov 12 10:43:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B0C3A6821 for ; Thu, 12 Nov 2009 10:43:48 -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 Lb8TQ2wWYM6s for ; Thu, 12 Nov 2009 10:43:47 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 659EB3A6816 for ; Thu, 12 Nov 2009 10:43:47 -0800 (PST) Received: by fxm7 with SMTP id 7so2581183fxm.29 for ; Thu, 12 Nov 2009 10:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=pK6mRhnVrJtWY/o1G630UPWeuX2Xuw0XMZOQdusKCbo=; b=qPh+k4r7apBj0oIgIQaYs5DQQE2vebh+8qvABOW1YjJBseIuy89PhN4ONr/g0bv/4P B4k8wekhYybhLmS0oRQDu8xo3fYjeMhuTptlhcYoQd7QndN6jhc4oXHUiX9pXvA+pl+Y xzz913uwOOyIfTs28YP4tl43Jq7myREh+WiJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=AO0lOO0VwQv2ehy8v3NgjS5TTbTqFpeOhm/iU95VDRFnOaFiQ/Nh36i9CDJlslL26q gEMItWGrPzlL1m5bDGzEEp6YjPAfoeUpnJy1PrZ/XicN2Tx06wRZyFt/RMxB9ageIXRB 4aN9NY1m48oz90cQ8eC8rUkxoFvefmAG7ISHg= Received: by 10.204.154.207 with SMTP id p15mr3560045bkw.202.1258051453130; Thu, 12 Nov 2009 10:44:13 -0800 (PST) Received: from ?10.100.1.196? (adsl132-189.ath.forthnet.gr [79.103.99.189]) by mx.google.com with ESMTPS id 1sm3171057fkt.11.2009.11.12.10.44.10 (version=SSLv3 cipher=RC4-MD5); Thu, 12 Nov 2009 10:44:11 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4AFC5779.3000306@gnutls.org> Date: Thu, 12 Nov 2009 20:44:09 +0200 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Chris Newman References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> <4AF455DF.5040106@stpeter.im> <57839EF28A3534D8E0C69AD4@446E7922C82D299DB29D899F> In-Reply-To: <57839EF28A3534D8E0C69AD4@446E7922C82D299DB29D899F> X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] TLS or HTTP issue? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 18:43:48 -0000 Chris Newman wrote: > 2. Having one authorized and authenticated TLS session decrypt data from > a different TLS session. This attack is most severe for > SMTP+STARTTLS+BDAT (since SMTP relays typically treat all senders as > authenticated as long as the recipient is in the local domain), but > impacts most application protocols that have a command to "send", > "post", "put", "set an attribute" or perform any write operation that > can subsequently be read back. In the case of IMAP, this can be used by > one authorized IMAP user (someone with an account on the IMAP server) to > potentially steal the login password of another IMAP user on the same > server (with some IMAP client behavior caveats). This attack is not obvious to me by this description. Can you please elaborate? regards, Nikos From mike-list@pobox.com Thu Nov 12 11:08:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A8C3A67E2 for ; Thu, 12 Nov 2009 11:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 QKbJVjYq7cRt for ; Thu, 12 Nov 2009 11:08:48 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 14C3A3A6778 for ; Thu, 12 Nov 2009 11:08:29 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 1A08A9C55D for ; Thu, 12 Nov 2009 14:08:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=cJNnc42UVjlW9YzJDtlI9d5Td zk=; b=GemIlpqWPdsZhVcLS6QOSmZEUB8skNT7j3ZtuGgpuQD1v1vUz+xgFwuVu aVpdw/XBKxmkgu/jb7bbLnex+H04S81BApP0t5Ok6vUCv8lhozL/WvYLgRcZG6s1 4E3W0au8Me9JU5EiLTCbSYAx+Z1Uiq1M97kCCVVRdCnIyoPnQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=e8ttD4lx0RAmKSvO7JE UIS4iNt8fPS81xa+OypP2vqx4CVfDt4z2gGJOhVV6o6YLIHjHn0ZzcVaM7knC6Yd CrIAqQpAAsTuMDw+JFcw8CDxd/mw3HJC5dYjEu8A0bf4468hD16/m2tjlwTG8hmD PMP5Kys+ELDl+WiPxuMcBBLE= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 16BAA9C55B for ; Thu, 12 Nov 2009 14:08:58 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id ACED99C55A for ; Thu, 12 Nov 2009 14:08:57 -0500 (EST) Message-ID: <4AFC5D80.2030101@pobox.com> Date: Thu, 12 Nov 2009 11:09:52 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D450CA92-CFBE-11DE-BE8F-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] webex X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 19:08:49 -0000 Is there a transcript available? Mike From mrex@sap.com Thu Nov 12 12:35:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763F33A68FA for ; Thu, 12 Nov 2009 12:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 gz37CI0GM4G5 for ; Thu, 12 Nov 2009 12:35:42 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5A3993A6956 for ; Thu, 12 Nov 2009 12:35:42 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nACKaAkf016135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 21:36:10 +0100 (MET) From: Martin Rex Message-Id: <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 12 Nov 2009 21:36:09 +0100 (MET) In-Reply-To: <20091112181844.GE1105@Sun.COM> from "Nicolas Williams" at Nov 12, 9 12:18:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:35:43 -0000 Nicolas Williams wrote: > > And I should add that the re-negotiation channel binding can be achieved > _without_ ServerHello extensions! If that means improved odds for > interop, then you should consider it. They could have, from the beginning of SSLv3... With other words: Currently Finished is defined for both, initial and renegotiate as: struct { opaque verify_data[verify_data_length]; } Finished; verify_data PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; finished_label For Finished messages sent by the client, the string "client finished". For Finished messages sent by the server, the string "server finished". If the original design had instead distinguished initial and renegotiation like this, the problem would not exist: verify_data for initial handshakes: PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; verify_data for renegotiation handshakes: PRF(master_secret, finished_label, verify_data_of_previous_session, Hash(handshake_messages)) [0..verify_data_length-1]; The whole effort with the TLS RI extension is to securely distinguish old from updated communication peers--provided they do not choke on TLS extensions. Forward signaling client->server that the client is updated through a special ciphersuite ID in the ciphersuite list of the ClientHello is still fairly easy and probably quite interoperable. Backwards signaling server->client that the server is updated is a little more difficult because one would have to repurpose an element of the ServerHello. If there really are SSL implemenations that fill the unix_gmt_time with all random data (instead of just fuzzing the lower bits of it), then that part requires a less "pure" approach. Maybe by confiscating a currently unused bit of the more tightly controlled value ranges of other members of the ServerHello handshake message (server_version.major, cipher_suite or compression_method). Of course, the server would then only signal back to use the secure finished message calculation for renegotiation handshakes, for which the client had indicate to understand that protocol change by including that special ciphersuites ID in the cipher_suites list of the ClientHello handshake message. ...but actually, we wanted to Last Call Eric's proposal, didn't we? -Martin From Nicolas.Williams@sun.com Thu Nov 12 12:49:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53893A69A7 for ; Thu, 12 Nov 2009 12:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027, 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 hrBnnsNP6IJk for ; Thu, 12 Nov 2009 12:49:54 -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 DA15A3A69A6 for ; Thu, 12 Nov 2009 12:49:53 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nACKoMkI011457 for ; Thu, 12 Nov 2009 20:50:22 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 nACKoMdQ041148 for ; Thu, 12 Nov 2009 13:50:22 -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 nACKclIi018614; Thu, 12 Nov 2009 14:38:47 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACKclpi018613; Thu, 12 Nov 2009 14:38:47 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 14:38:47 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091112203847.GL1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:49:54 -0000 On Thu, Nov 12, 2009 at 09:36:09PM +0100, Martin Rex wrote: > Backwards signaling server->client that the server is updated is > a little more difficult because one would have to repurpose an element > of the ServerHello. If there really are SSL implemenations that fill > the unix_gmt_time with all random data (instead of just fuzzing the > lower bits of it), then that part requires a less "pure" approach. > > Maybe by confiscating a currently unused bit of the more tightly > controlled value ranges of other members of the ServerHello handshake > message (server_version.major, cipher_suite or compression_method). The whole point of my post was to point out that there is a way to do the server->client signaling without changing a single bit on the wire -- just the Finished message computations. Interestingly, that approach could even be used on initial connections to detect if the server will support secure re-negotiation _before_ the client ever tries it. > ...but actually, we wanted to Last Call Eric's proposal, didn't we? Yes. That's why I wrote "[i]f [my alternative proposal] means improved odds for interop, then you should consider it". If we have consensus that EKR's fix is sufficient, then we should just move forward with it. (I've not followed all of the SSLv3 sub-threads, so I'm not sure if my proposal would help w.r.t. SSLv3. I leave that to you to figure out.) Nico -- From Nicolas.Williams@sun.com Thu Nov 12 17:05:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4513A69E1 for ; Thu, 12 Nov 2009 17:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, 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 D9gctWrs7O9z for ; Thu, 12 Nov 2009 17:05:25 -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 86CA73A6A9A for ; Thu, 12 Nov 2009 17:05:25 -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 nAD15sJc008098 for ; Fri, 13 Nov 2009 01:05:54 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 nAD15sbb038359 for ; Thu, 12 Nov 2009 18:05:54 -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 nAD0sJT0018961; Thu, 12 Nov 2009 18:54:19 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAD0sJLE018960; Thu, 12 Nov 2009 18:54:19 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 12 Nov 2009 18:54:19 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091113005419.GQ1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: [TLS] Comments on draft-rescorla-tls-renegotiate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 01:05:26 -0000 Comments: 1) The rest of this comment can be ignored if the use of protocol extensions in draft-rescorla-tls-renegotiate is deemed to not be a problem. I believe this problem can be fixed without using protocol extensions at all. All that has to be done is this: for re-negotiations the Finished message computation changes from this: PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; to: PRF(master_secret, finished_label, Hash(handshake_messages || outer_connection_client_finished)) [0..verify_data_length-1]; where outer_connection_client_finished is the client Finished message for the previous/old/outer TLS connection There is no need to signal this! Either both, the client and the server will do this, or not do it, in which case the Finished messages will check out on both sides, or one will do it and the other won't, in which case the Finished messages will fail to check out on both sides. If there's a MITM and the client and server both do this, then the MITM will be detected. I.e., channel binding is the solution, but there's no need to negotiate it -- the server wouldn't accept re-negotiation from clients that don't support the fix anyways. If there's no need to negotiate the fix, then there's no need to use Hello extensions. Also, this scheme allows both, the client and the server, to securely determine whether the other implemented the fix or not. This is potentially a good or bad thing, depending on your point of view, since it allows for implementations to have an option to fallback on insecure behavior. 2) I believe the I-D, if the fix is not modified, should have the following INFORMATIVE text added: " This solution is akin to channel binding [RFC5056] using the 'tls-unique-for-telnet' channel binding type [I-D.altman-tls-channel-bindings]. This is not a generic channel binding facility however. " RFC5056 and draft-altman-tls-channel-bindings-07.txt should be added as informative references. (draft-altman-tls-... is currently listed as a normative reference.) Nico -- From mrex@sap.com Thu Nov 12 17:50:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4326C3A67E4 for ; Thu, 12 Nov 2009 17:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 OvsRGq5+BOub for ; Thu, 12 Nov 2009 17:50:11 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 99F533A6358 for ; Thu, 12 Nov 2009 17:50:11 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAD1odl1028109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2009 02:50:39 +0100 (MET) From: Martin Rex Message-Id: <200911130150.nAD1ock5004848@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 13 Nov 2009 02:50:38 +0100 (MET) In-Reply-To: <20091113005419.GQ1105@Sun.COM> from "Nicolas Williams" at Nov 12, 9 06:54:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 01:50:13 -0000 Nicolas Williams wrote: > > Comments: > > 1) The rest of this comment can be ignored if the use of protocol > extensions in draft-rescorla-tls-renegotiate is deemed to not be a > problem. > > I believe this problem can be fixed without using protocol extensions > at all. All that has to be done is this: for re-negotiations the > Finished message computation changes from this: > > PRF(master_secret, finished_label, Hash(handshake_messages)) > [0..verify_data_length-1]; > > to: > > PRF(master_secret, finished_label, > Hash(handshake_messages || outer_connection_client_finished)) > [0..verify_data_length-1]; > > where outer_connection_client_finished is the client Finished message > for the previous/old/outer TLS connection > > There is no need to signal this! If you do not signal, then your client will not be able to detect whether it is talking to an old server, in which case the clients initial handshake might still be proxied into the renegotiation of that old server. If there is a signaling in both directions available, and the client does not receive an indicator in the ServerHello that it is talking to an Updated Server, then it can never warn and offer to not connect (some people seem to want that option). Similarly, if you do not get a feedback in the ServerHello telling you whether that server is an updated server or not, then your client can not agree to an old insecure renegotiation (there might be environments where the connectivity and possibility to renegotiate is desired, and the MITM-susceptibility not considered a problem. If you want to provide the consumers those options, you will need signaling. When changing the calculation of the verify_data of the finished messages for renegotiation, then the only information that needs to be signaled is that the other side is updated. Apparently there are some network monitoring folks that would like to be able to distinguish patched from unpatched TLS implementations. They might want signaling. You could have the servers signal with the highest bit of the protocol server_version in the ServerHello that they're using a secured (i.e. different from the base protocol version) finished message calculation for renegotiations, provided that the client has indicated support for recognizing this modified server_version in the ServerHello, indicating that the client is actually talking to an updated server. For TLS v1.3, the secure renegotiation Finished message calculation could be made the default, and then it would no longer be necessary to have the server modify its protocol version number for protocol versions >=1.3. Old clients would still get the old protocol version back on the ServerHello. Updated clients asserting the special ciphersuite ID would receive: server_version 0x03,0x00 unpatched server, SSLv3 protocol, original finished calc 0x03,0x01 unpatched server, TLSv1.0 protocol, original finished calc 0x03,0x02 unpatched server, TLSv1.1 protocol, original finished calc 0x03,0x03 unpatched server, TLSv1.2 protocol, original finished calc 0x83,0x00 patched server, SSLv3 protocol, secure renego finished 0x83,0x01 patched server, TLSv1.0 protocol, secure renego finished 0x83,0x02 patched server, TLSv1.1 protocol, secure renego finished 0x83,0x03 patched server, TLSv1.2 protocol, secure renego finished and in the future: 0x03,0x04 new server, TLSv1.3 protocol, secure renego finished If we're modifying the calculation for the finished messages for the renegotiation handshake to include the verify_data of the previous session, then this is a protocol change, and indicating this in the protocol version of the ServerHello is _no_ abuse. :) If the client wants to (a) still talk or somewhat dangerous (b) still renegotiate in the unprotected traditional fashion with an old server, it can do so, because it determine from the server_version in ServerHello whether the server is patched and which Finished message calculation the server will be using. -Martin From jsalowey@cisco.com Thu Nov 12 21:11:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8093A67AB for ; Thu, 12 Nov 2009 21:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.666 X-Spam-Level: X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 s6Aln051IAql for ; Thu, 12 Nov 2009 21:11:06 -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 B74E93A6767 for ; Thu, 12 Nov 2009 21:11:06 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADJ5/EqrR7Ht/2dsb2JhbAC9NJgphDwEgW0 X-IronPort-AV: E=Sophos;i="4.44,733,1249257600"; d="scan'208";a="431548107" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 13 Nov 2009 05:11:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAD5BaSB027928; Fri, 13 Nov 2009 05:11:36 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.3959); Thu, 12 Nov 2009 21:11:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 21:11:34 -0800 Message-ID: In-Reply-To: <4AFC5D80.2030101@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] webex Thread-Index: Acpjy6jaz73ZbwSPQJei7o6jyHiUgQAUpG8Q References: <4AFC5D80.2030101@pobox.com> From: "Joseph Salowey (jsalowey)" To: "Michael D'Errico" , X-OriginalArrivalTime: 13 Nov 2009 05:11:36.0616 (UTC) FILETIME=[C63D7280:01CA641F] Subject: Re: [TLS] webex X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 05:11:08 -0000 I don't know about the webex, but the jabber logs are available here http://www.ietf.org/jabber/logs/tls/2009-11-12.txt and the audio is available here ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ and I think TLS is this one ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch4-thur-afn oon2.mp3. I'm not sure if the webex chat was saved. =20 Joe > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Michael D'Errico > Sent: Thursday, November 12, 2009 11:10 AM > To: tls@ietf.org > Subject: [TLS] webex >=20 > Is there a transcript available? >=20 > Mike > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From ekr@networkresonance.com Thu Nov 12 21:58:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19033A6833 for ; Thu, 12 Nov 2009 21:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z838M2k2BC1p for ; Thu, 12 Nov 2009 21:58:35 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id CC1E83A682A for ; Thu, 12 Nov 2009 21:58:34 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N8pBX-0003D5-00 for tls@ietf.org; Fri, 13 Nov 2009 07:59:03 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 55DC569F31E; Fri, 13 Nov 2009 08:00:04 +0200 (EET) Date: Fri, 13 Nov 2009 08:00:04 +0200 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4AFC46D8.9050905@pobox.com> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091113060004.55DC569F31E@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 05:58:35 -0000 At Thu, 12 Nov 2009 09:33:12 -0800, Michael D'Errico wrote: > > Eric Rescorla wrote: > > At Tue, 10 Nov 2009 09:08:20 -0800, > > Michael D'Errico wrote: > >> A client that wants protection from this attack MUST send the extension > >> in its initial handshake. Why don't you want to do that? > >> > >> The attack being discussed happens on the client's *initial* handshake. > >> The server sees it as a renegotiation, so the client needs to be able to > >> tell the server that it thinks it is performing an initial handshake. > >> That is exactly what this extension provides. If you don't send the > >> extension on an initial handshake you are risking being attacked. > > > > I don't see that that's the case: you're risking being attacked in > > any case if the server is not upgraded. > > My point was that if the server *is* upgraded and the client does not > send the extension on its initial handshake, it is taking an unnecessary > risk. The issue isn't whether the client sends it. Of course the client sends it. It's whether the client aborts the connection of the server doesn't return it. -Ekr From ekr@networkresonance.com Fri Nov 13 00:21:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2528D3A68D1 for ; Fri, 13 Nov 2009 00:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z7AGSVZ4jka for ; Fri, 13 Nov 2009 00:21:05 -0800 (PST) Received: from kilo.networkresonance.com (unknown [194.126.108.9]) by core3.amsl.com (Postfix) with ESMTP id 249FF3A682A for ; Fri, 13 Nov 2009 00:21:05 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C55F469F381; Fri, 13 Nov 2009 10:22:35 +0200 (EET) Date: Fri, 13 Nov 2009 10:22:35 +0200 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20091112203847.GL1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091113082235.C55F469F381@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 08:21:06 -0000 At Thu, 12 Nov 2009 14:38:47 -0600, Nicolas Williams wrote: > > On Thu, Nov 12, 2009 at 09:36:09PM +0100, Martin Rex wrote: > > Backwards signaling server->client that the server is updated is > > a little more difficult because one would have to repurpose an element > > of the ServerHello. If there really are SSL implemenations that fill > > the unix_gmt_time with all random data (instead of just fuzzing the > > lower bits of it), then that part requires a less "pure" approach. > > > > Maybe by confiscating a currently unused bit of the more tightly > > controlled value ranges of other members of the ServerHello handshake > > message (server_version.major, cipher_suite or compression_method). > > The whole point of my post was to point out that there is a way to do > the server->client signaling without changing a single bit on the wire > -- just the Finished message computations. > > Interestingly, that approach could even be used on initial connections > to detect if the server will support secure re-negotiation _before_ the > client ever tries it. I don't see that. AFAICT both your options involve the client generating a hello extension, so this does affect the bits on the wire. Obviously there are approaches which don't require that, but they don't provide detection of server capabilities on initial negotiation. By contrast your message of 1854 doesn't allow the client to probe the server AFAICT. -Ekr From mrex@sap.com Fri Nov 13 07:34:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2763A6981 for ; Fri, 13 Nov 2009 07:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 dLahA6dzY0-d for ; Fri, 13 Nov 2009 07:34:32 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id F35433A695A for ; Fri, 13 Nov 2009 07:34:31 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nADFYx3t011993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2009 16:34:59 +0100 (MET) From: Martin Rex Message-Id: <200911131534.nADFYxDa020395@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 13 Nov 2009 16:34:59 +0100 (MET) In-Reply-To: <20091113082235.C55F469F381@kilo.networkresonance.com> from "Eric Rescorla" at Nov 13, 9 10:22:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: [TLS] Protected Renegotiation -- refined proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 15:34:33 -0000 Eric Rescorla wrote: > > Nicolas Williams wrote: > > > > The whole point of my post was to point out that there is a way to do > > the server->client signaling without changing a single bit on the wire > > -- just the Finished message computations. > > > > Interestingly, that approach could even be used on initial connections > > to detect if the server will support secure re-negotiation _before_ the > > client ever tries it. > > I don't see that. AFAICT both your options involve the client generating a > hello extension, so this does affect the bits on the wire. Obviously > there are approaches which don't require that, but they don't provide > detection of server capabilities on initial negotiation. By contrast > your message of 1854 doesn't allow the client to probe the server > AFAICT. Nico an I are talking about slighty different things. I will try to reexplain my most recent mind model of how this should be solved, and you will see that the cryptographic properties are almost identical to the TLS extension RI. My most recent model will actually grow naturally into TLS v1.3 and become invisible. The cryptographic concept behind the actual fix: I. Initial SSL/TLS Handshake on a connection Here we want to achieve three things: a) Securely signal from client to server that client is updated b) Securely signal from server to client that server is updated (provided that client has indicated that it will understand this information) c) Signal that this is an initial handshake so that it can not be proxied into a renegotiation handshake in an abstract fashion, the protocol update looks like this: Initial SSL/TLS handshake on a connection Traditional: Updated: ClientHello ClientHello + ProtocolUpdateIndicatorC2S ServerHello ServerHello + ProtocolUpdateIndicatorS2C -- all further handshake messages unchanged --- TLS extension RI: (1a) + (1c) For the TLS extension RI, the ProtocolUpdateIndicatorC2S is a ClientHelloExtension "RI" with empty data (1b) + (1c) For the TLS extension RI, the ProtocolUpdateIndicatorS2C is a ServerHelloExtension "RI" with empty data Both ProtocolUpdateIndicators have no special cryptographic properties. They're part of the handshake messages so that can not be stripped from an MITM without breaking the MAC-check by the Finished messages. My (revised) proposal: My proposal is to use two other ProtocolUpdateIndicators instead that can be added to all existing protocol versions with significantly less pain an suffering, and in a fully fowards compatible fashion so that this ProtocolUpdate will grow out naturally with the next TLS protocol update (TLSv1.3) (1a) assign a special ciphersuites ID as ProtocolUpdateIndicatorC2S that is to be included in the ciphersuites list of the ClientHello and extremely backwards compatible with installed base servers that implement SSLv3->TLSv1.2 (0x03,0x00) -> (0x03,0x03). (1c) change the computation of the finished mac for all renegotiation handshakes (1b) increase the major number of the protocol version by one as the ProtocolUpdateIndicatorS2C, which means: 0x03,0x00 SSLv3, unpatched 0x04,0x00 SSLv3 patched 0x03,0x01 TLSv1.0, unpatched 0x04,0x01 TLSv1.0 patched 0x03,0x02 TLSv1.1, unpatched 0x04,0x02 TLSv1.1 patched 0x03,0x03 TLSv1.2, unpatched 0x04,0x03 TLSv1.2 patched (0x03,0x04 TLSv1.3 only for client_version) 0x04,0x04 TLSv1.3 (1a2) A client that sends a ClientHello with a client_version that is >=0x03,0x04 also indicates that it will used the changed computation of finished mac calculation for the renegotiation handshake. II. Renegotiation SSL/TLS handshake on a connection Here we want to achieve: a) cryptographic binding of the renegotiation handshake to the previous session by adding the verify_data of the previous finished messages as known to the client into the handshake message hash (->ClientVerify, ->Finished) b) cryptographic binding of the renegotiation handshake to the previous session by adding the verify_data of the previous finished messages as known to the server into the handshake message hash (->ClientVerify, ->Finished) Renegotiation SSL/TLS handshake on a connection Traditional: Updated: ClientHello ClientHello + ClientsPreviousVerifyData ServerHello ServerHello + ServersPreviousVerifyData -- all further handshake messages unchanged --- TLS extension RI: (2a) adds the clients verify_data from previous client.finished message into ClientHelloExtension RI (2b) adds the servers verify_data from previous (client.finished and) server.finished message into ServerHelloExtension RI The Handshake Messages MAC will roughly receive the following data: ClientHello FF 01 00 01 0C ServerHello FF 01 00 01 18 -- all further handshake messages unchanged --- My (revised) proposal: (2a)+(2b) effectively change the computation of the finished macs by redefining what goes into the handshake message hash if the updated protocol is used. The verify_data of the previous client.finished and server.finished messages are defined to be handshake messages that are _not_ sent in the current handshake (think of it as carryover from the previous handshake). The Handshake Messages MAC will roughly receive the following data: Client-side: ClientHello ServerHello -- all further handshake messages unchanged --- Server-side: ClientHello ServerHello -- all further handshake messages unchanged --- The verify_data should become a "virtual handshake message" _after_ the ServerHello, when client and server both know that they're really using the updated protocol. To me, it looks like this approach and TLS extension RI are very similar in their cryptographic properties. By adding the verify_data to the handshake message MACs (but not the message stream) always after ServerHello, they are also covered by the clients signature in the ClientVerify message -- in case that cert-based SSL/TLS client authentication is used. This property is also similar to TLS extension RI. If the clients memories about the previous session differ from those of the server, the finished messages of the renegotiation handshake will differ. If client cert authentication is used, the signature verification of ClientVerify will already fail. -Martin From mike-list@pobox.com Fri Nov 13 08:09:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E8F3A67B0 for ; Fri, 13 Nov 2009 08:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 yb79xOTXb4y5 for ; Fri, 13 Nov 2009 08:09:24 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 5C58C3A67A5 for ; Fri, 13 Nov 2009 08:09:23 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D440E7FB17 for ; Fri, 13 Nov 2009 11:09:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=UG0ADfV8ty9L JoGUo7g7+rd9/VA=; b=rMpQGzSw6c8HEO9oKi/chreZCFnJT02wDCQiXMuqIQvo 0FasthxzstdfM5tN67hEyyokez0tlUtjuuPda1OO8FGyGlCCK2/vZQnr8I/vysep f0CiXcloM8cIps1/Vnqb3IIxPuh+QEWffnU/HzhKCmQnqhzLZKVqibqp6lNONKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=uKpWgj glZpdtTldPkDe33Aeqgdsgk+DOp1rDhoXhKWEouxHDJKOpxvfLrEXlShKJpb2wRn 5SgUOd9WyWYLWNUWeYXy3O92uPfEP3gazV41KadB4F7CbVz+B/nZyG1vrISfX75i /KlK/CDInqiPOy81WqRvY3brGWNwjd2HJ/BlA= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D0D2D7FB16 for ; Fri, 13 Nov 2009 11:09:52 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 810AB7FB15 for ; Fri, 13 Nov 2009 11:09:52 -0500 (EST) Message-ID: <4AFD850C.7010704@pobox.com> Date: Fri, 13 Nov 2009 08:10:52 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> In-Reply-To: <20091113060004.55DC569F31E@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: FA136590-D06E-11DE-A2DE-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:09:25 -0000 >> My point was that if the server *is* upgraded and the client does not >> send the extension on its initial handshake, it is taking an unnecessary >> risk. > > The issue isn't whether the client sends it. Of course the client > sends it. It's whether the client aborts the connection of the server > doesn't return it. I'm in agreement with you that the client should send the extension. But there have been messages suggesting that a client doesn't need to send it on its initial connection, only when renegotiating. I've been trying to convince them that the client must send it especially in its first handshake in order to avoid being attacked. Mike From marsh@extendedsubset.com Fri Nov 13 08:14:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB533A69AB for ; Fri, 13 Nov 2009 08:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 aMrcomdu-lyT for ; Fri, 13 Nov 2009 08:14:45 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 07DF03A6894 for ; Fri, 13 Nov 2009 08:14:45 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N8ynq-0006Y3-B0 for tls@ietf.org; Fri, 13 Nov 2009 16:15:14 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id EE3236678 for ; Fri, 13 Nov 2009 16:15:11 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/bvk2f2A/Q+Ve02AK2TUMC5VwztAIsz1c= Message-ID: <4AFD860F.8060007@extendedsubset.com> Date: Fri, 13 Nov 2009 10:15:11 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <4AFD850C.7010704@pobox.com> In-Reply-To: <4AFD850C.7010704@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:14:46 -0000 Michael D'Errico wrote: > But there have been messages suggesting that a client doesn't need to > send it on its initial connection, only when renegotiating. I've > been trying to convince them that the client must send it especially > in its first handshake in order to avoid being attacked. Yes, that's the basis of the main attack: the client doesn't realize that he's renegotiating. - Marsh From mrex@sap.com Fri Nov 13 08:39:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B912E3A67A5 for ; Fri, 13 Nov 2009 08:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 yJhpuWlZhGAb for ; Fri, 13 Nov 2009 08:39:18 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id C15E53A67A1 for ; Fri, 13 Nov 2009 08:39:17 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nADGdk1f024737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2009 17:39:46 +0100 (MET) From: Martin Rex Message-Id: <200911131639.nADGdjH8023899@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 13 Nov 2009 17:39:45 +0100 (MET) In-Reply-To: <200911131534.nADFYxDa020395@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 13, 9 04:34:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Protected Renegotiation -- refined proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:39:18 -0000 Two inaccuracies in my last posting: Martin Rex wrote: > > Renegotiation SSL/TLS handshake on a connection > > TLS extension RI: > > ClientHello > FF 01 00 01 0C > > ServerHello > FF 01 00 01 18 > > > -- all further handshake messages unchanged --- Mike quite helpfully pointed out that I got the length fields wrong in my illustration for the TLS extensions, they would rather look like FF 01 00 0D 0C FF 01 00 19 18 > > My (revised) proposal: > > The Handshake Messages MAC will roughly receive the following data: > > Client-side: > > ClientHello > ServerHello > > > -- all further handshake messages unchanged --- > > Server-side: > > ClientHello > ServerHello > > > -- all further handshake messages unchanged --- Any in my (revised) proposal, the ClientHello and ServerHello would contain the signaling C->S (special ciphersuite ID) and S->C (protocol version with 0x04 major number) in both handshakes, initial and renegotiation. -Martin From Nicolas.Williams@sun.com Fri Nov 13 08:57:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CAA28C0D0 for ; Fri, 13 Nov 2009 08:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, 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 Vpe-ls7wArkx for ; Fri, 13 Nov 2009 08:57:16 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3CA0228C0E3 for ; Fri, 13 Nov 2009 08:57:16 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nADGvk8B017553 for ; Fri, 13 Nov 2009 16:57:46 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 nADGvkbW030529 for ; Fri, 13 Nov 2009 09:57:46 -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 nADGkBKw019149; Fri, 13 Nov 2009 10:46:11 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nADGk9k4019148; Fri, 13 Nov 2009 10:46:09 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 13 Nov 2009 10:46:09 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091113164608.GT1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091113082235.C55F469F381@kilo.networkresonance.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:57:17 -0000 On Fri, Nov 13, 2009 at 10:22:35AM +0200, Eric Rescorla wrote: > At Thu, 12 Nov 2009 14:38:47 -0600, > Nicolas Williams wrote: > > Interestingly, that approach could even be used on initial connections > > to detect if the server will support secure re-negotiation _before_ the > > client ever tries it. > > I don't see that. AFAICT both your options involve the client generating a > hello extension, so this does affect the bits on the wire. Obviously > there are approaches which don't require that, but they don't provide > detection of server capabilities on initial negotiation. By contrast > your message of 1854 doesn't allow the client to probe the server > AFAICT. The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 yesterday most certainly described no Hello extensions, only a Finished message verify_data computation change. Nico -- From mike-list@pobox.com Fri Nov 13 09:03:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF7A3A67D7 for ; Fri, 13 Nov 2009 09:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Ra0X8YFyosDG for ; Fri, 13 Nov 2009 09:03:52 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 992633A67E3 for ; Fri, 13 Nov 2009 09:03:52 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 61C729EB3C for ; Fri, 13 Nov 2009 12:04:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=jM/8hbsBW3K9 iSWlJVBaTUzfgb8=; b=IGpqM0KkxxyIwuufpZMsXqoogiXpcXSbM1GI3JtWT5x4 aIlzrqrafw2hy4zEY4OBQ6z95AmvMaU2CrhmaVbjkDrVIpqO9ZJDsYMh+5PBB1t3 9XBg5e4hWevH3zL5zK7jOPv33aAx/Y0VtTaW7+/vN45/alKSCLNXy2bJwfXLiFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=c5fYvw 5AQel/mmc6cFDPrH3gqvHuX9y0YUJo1aM6U3bpN7D2slXY2Zb/zVIjADapB/Rf1A PkvqzTWlFf4ElMh3p0MLdEtWphmdDQAGo4w7u00irX/NOpoh/HlST20/ddur5LEw XmOKtpPhvDQhpFVgKcj2HALTs4+daSceiVkP4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5C63A9EB3A for ; Fri, 13 Nov 2009 12:04:22 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 052159EB38 for ; Fri, 13 Nov 2009 12:04:21 -0500 (EST) Message-ID: <4AFD91D1.7030409@pobox.com> Date: Fri, 13 Nov 2009 09:05:21 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AFC5D80.2030101@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 96DB393C-D076-11DE-A2B8-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] webex X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 17:03:53 -0000 > the jabber logs are available here > http://www.ietf.org/jabber/logs/tls/2009-11-12.txt I noticed in the logs that there was discussion of wanting to have two separate opaque values, I assume one for the client verify data and the other for the server verify data. What is the status of this change? Mike From Nicolas.Williams@sun.com Fri Nov 13 09:43:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A5C3A68C1 for ; Fri, 13 Nov 2009 09:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, 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 vlOl56kj5Ftj for ; Fri, 13 Nov 2009 09:43:19 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 43FD13A6900 for ; Fri, 13 Nov 2009 09:43:19 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nADHhnag024332 for ; Fri, 13 Nov 2009 17:43:49 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 nADHhmpP037381 for ; Fri, 13 Nov 2009 10:43:48 -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 nADHWEIV019188; Fri, 13 Nov 2009 11:32:14 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nADHWExn019187; Fri, 13 Nov 2009 11:32:14 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 13 Nov 2009 11:32:14 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091113173214.GW1105@Sun.COM> References: <20091111121708.EF62069EDB2@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091111121708.EF62069EDB2@kilo.networkresonance.com> User-Agent: Mutt/1.5.7i Cc: draft-solinas-tls-additional-prf-input@tools.ietf.org, tls@ietf.org Subject: Re: [TLS] Comments on draft-solinas-tls-additional-prf-input X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 17:43:20 -0000 On Wed, Nov 11, 2009 at 01:17:08PM +0100, Eric Rescorla wrote: > Despite not being clear on what this is for, I don't have a problem > with there being a code point assigned for this extension for USG use. > However, I don't think that some of the proposed uses are in > fact appropriate and would like to see the document revised accordingly. > > In particular, there are two potential things one might be trying > to do here: > > 1. Add additional randomness into the PRF. > 2. Add structured, meaningful data into the PRF. 3. Add channel binding to other channels (for TLS, outside re-negotiation, this is extremely unlikely; no one is likely to care about TLS-to-IPsec channel binding for many years to com) 4. Provide integrity protection to application-layer negotiations that precede the TLS handshake. Think of the "StartTLS" pattern in a large variety of protocols, including LDAP and HTTP (as opposed ldaps and https), where one might want to protect any pre-starttls negotiations (possibly by hashing pre-starttls messages and using them as the additional input). 5. Prove that out-of-band data (other than the type described in (4)) is the same on the client and server sides. There may be others. Examples of (3) and (4) exist. Example of (3): SCRAM uses channel binding. Example of (4): SASL/GS2 uses the GSS-API channel binding facility to protect data sent outside GSS-API context tokens. Another example of (4): a recent addition to OpenSolaris, a remote audit protocol, uses the GSS-API channel binding facility to protect application protocol version negotiation. (3) may well be useless in TLS, outside the context of re-negotiation anyways (where your fix is, effectively, to add a non-generic channel binding from the inner to the outer connection). (4) is, IMO, incredibly useful. Paul seemed to misunderstand me the other day and cut me off before I could explain that a channel binding facility is not _only_ about channel binding, that there are uses for such a thing that are not actually channel binding. I have no examples of (5). In very specific cases it may be useful. (5) could also be used as a way to add a PSK-like component to TLS, but one would have to be careful about how to identify a key for that. > AFAICT, the first of these is useless but harmless: useless because > the security guarantees of TLS require only uniqueness of the > Random values, not unpredictability, and 28 bytes is far more than > required to provide a statistical guaranteee of uniqueness; harmless > because the PRF can easily absorb additional new data, even if it > is completely nonrandom. Agreed. > The second, however, is a backdoor method of extending TLS and the > semantics are completely different: in order to be useful, the > data in the extension must be processed and potentially checked > by the other side. Several mechanisms for extending TLS already > exist (TLS Extensions and then the TLS Supplemental Data > message) and should not add yet another generic mechanism > here. You might argue that (4) is like (2), but then you'd also be saying that the StartTLS pattern is a "backdoor method of extending TLS". One might see StartTLS as such a thing, but that ship has sailed. I think (4) is reason enough to have this feature in TLS. You might argue that (3) will be useless (as I explained). And you might argue that (5) is dangerous or undesirable. Even if we all were to agree about (3) and (5), we'd still have (4). > I don't have a problem with an opaque field here, since that's > really just a private code point assignment. But having it > have actual semantics leaks into TLS and I do object to that. I don't agree. See above. I do, however, have comments on the mechanics of this extension, but I'll leave those for another day. > S 1.1. > Several recommendations for key derivation call for the concatenation > of additional information fields into the key derivation function > when producing a shared key. For example, the specification of > Alternative 1 in NIST Special Publication 800-56A ([SP800-56A]) calls > for the inclusion of "OtherInfo" fields. In this case, OtherInfo > contains the concatenation of a variety of mandatory and optional > sub-fields. The extension described in this document provides a > simple mechanism both for supplying the public information to the > peer and for the inclusion of the information in the key derivation. > Many other application environments require or allow similar fields. > > This actually seems extremely dangerous. AFAICT the point of these > OtherInfo fields is that they are explicitly bound into the PRF > on both sides. In order to be useful (as opposed to formally present), > OtherInfo needs to be explicitly produced/verified by each side. > This needs to be removed. Agreed. Nico -- From mrex@sap.com Fri Nov 13 10:36:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417C93A6949 for ; Fri, 13 Nov 2009 10:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.078, 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 Jx4MInTskj4J for ; Fri, 13 Nov 2009 10:36:46 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D10143A68B5 for ; Fri, 13 Nov 2009 10:36:45 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nADIb6xF013134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2009 19:37:06 +0100 (MET) From: Martin Rex Message-Id: <200911131837.nADIb6GY000472@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 13 Nov 2009 19:37:06 +0100 (MET) In-Reply-To: <4AFB2B42.9060602@extendedsubset.com> from "Marsh Ray" at Nov 11, 9 03:23:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 18:36:47 -0000 Marsh Ray wrote: > > Well, if the remote endpoint allows you to initiate a renegotiation. MS > IIS for example responds with a TCP RST, other implementations may be > less direct. >From what Nico said in earlier messages about the Programming Model for Microsoft's TLS implementation (schannel SSP), the code above SSPI must know an implement a lot of TLS message flow. According to that sketch, performing a TLS handshake requires a significant amount of code above SSPI, and performing a TLS renegotiation requires an awful huge amount of code above SSPI. I have never used schannel myself (and haven't found programming examples yet), but it seems that the app on top of SSPI _must_ know whether incoming data is application data, protected application data or handshake messages and pass each of them to distinct SSPI calls or get an error. The return calls of those SSPI functions probably indicate which call to do next (or which kind of data to expect next). So an app on top of SSPI using the schannel SSP might not expect the client to request rekeying at arbitrary times during communication and that unexpected (protected) ClientHello handshake message is then passed to a Message-unprotection call of SSPI where it is rejected. When that happens, the server seems to terminate the session (delete the security context) and close the socket/connection, which might be the reason why you receive a TCP RST. Nico also mentioned, that with SSPI, the renegotiation context uses a different/seperate context handle that the original context. Which seems to imply, that for a TLS renegotiation by the app on top of SSPI, the app has to call the message protection/unprotection calls of the previous context for the initial handshake messages of the new context -- until the Interator Function(s) indicate that this is no longer necessary (because ChangeCipherSpec has been sent). If TLS renegotiation actually works like this in SSPI, then an SSPI app is actually playing the MITM-Attack every time that it renegotiates (i.e. it would perform the MITM-Attack on its own TLS stack). -Martin From rdugal@certicom.com Fri Nov 13 11:28:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9C93A6A37 for ; Fri, 13 Nov 2009 11:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 csmYs0GBU1HN for ; Fri, 13 Nov 2009 11:28:26 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id E65A03A6978 for ; Fri, 13 Nov 2009 11:28:25 -0800 (PST) X-AuditID: 0a666446-b7bc0ae000003d34-d2-4afdb3767777 Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id C3.55.15668.673BDFA4; Fri, 13 Nov 2009 14:28:54 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 14:28:53 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6497.897F9A0D" Date: Fri, 13 Nov 2009 14:28:53 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: client and server verify_data in draft-rescorla-tls-renegotiate.txt Thread-Index: Acpkl4lLUwKu2BjRRpmRwJGW2j+RKQ== From: "Robert Dugal" To: X-OriginalArrivalTime: 13 Nov 2009 19:28:53.0789 (UTC) FILETIME=[892F2CD0:01CA6497] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 19:28:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6497.897F9A0D Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable A co-worker an I have been discussing the draft and have some concerns about sending client and server verify_data in the extension. In the ClientHello, the client sends the verify_data from the client's previous Finish message as the renegotiated_connection data. In the ServerHello, the server sends both the cient's verify_data and the server's verify_data. This data is not normally sent in the clear and I am wondering if this will provide additional data that can be used to mount some other form of attack . The only reason we are sending any data at all is to prove that the renegotiation is bound to a previous handshake, so why not bind it with some data that is on the wire and visible to everyone? One possability is to use the client and server randoms as the renegotiated_connection data. This data is sent as plaintext on the wire so it reveals nothing the attacker doesn't already know. If these randoms are included in the client hello's renegotiation_connection data then they will also be included in the client and server message hashes. Likewise, if they are missing from the renegotiation_connection data an attacker cannot add them or else client and server message hashes will mismatch and renegotiated handshake will fail. Another alternative could be to use the client's encrypted Finish message rather than the verify_data from Client's Finish message, and server's encrypted Finish message. Again both these data are sent on the wire so reveal nothing. It's probably easier to use the randoms as handshake and record layer may not be able interchage data. -- Robert Dugal Senior Software Developer Certicom Corp. A Subsidiary of Research In Motion rdugal@certicom.com direct 905.501.3848 fax 905.507.4230 www.certicom.com ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CA6497.897F9A0D Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

A co-worker an I have been discussing the draft and hav= e some concerns about sending client and server verify_data in the extension.<= o:p>

In the ClientHello, the client sends the verify_data fr= om the client's previous Finish message as the renegotiated_connection data.

In the ServerHello, the server sends both the cient's verify_data and the server's verify_data.

This data is not normally sent in the clear and I am wondering if this will provide additional data that can be used to mount som= e other form of attack .   

The only reason we are sending any data at all is to pr= ove that the renegotiation is bound to a previous handshake, so why not bind it with some data that is on the wire and visible to everyone?

 

One possability is to use the client and server randoms= as the renegotiated_connection data.  This data is sent as plaintext on th= e wire so it reveals nothing the attacker doesn't already know.

If these randoms are included in the client hello's renegotiation_connection data  then they will also be included in the client and server message hashes.

Likewise, if they are missing from the renegotiation_co= nnection data  an attacker cannot add them or else client and server  messa= ge hashes will mismatch and renegotiated handshake will fail.

 

Another alternative could be to use the client's encryp= ted Finish message rather than the verify_data from Client's Finish message, and server= 's encrypted Finish message.

Again both these data are sent on the wire so reveal nothing.  It's probably easier to use the randoms as handshake and reco= rd layer may not be able interchage data.

 

--=

Robert D= ugal      &n= bsp;            =      Senior Software Developer=

Certicom= Corp.      &n= bsp;            = A Subsidiary of Research In Motion=

rdugal@certicom.com

direct      &n= bsp; 905.501.3848

fax             905.507.4230

www.certicom.com

 

---------------------------------------------------------------------
= =0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CA6497.897F9A0D-- From mike-list@pobox.com Fri Nov 13 11:50:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E833A6A50 for ; Fri, 13 Nov 2009 11:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 rRfbeouJphjy for ; Fri, 13 Nov 2009 11:50:30 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id B23793A677D for ; Fri, 13 Nov 2009 11:50:30 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5FB927F1DC for ; Fri, 13 Nov 2009 14:50:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=BzdfFT4/LBbw GLUXnKPLcc7dwI0=; b=R5mVD5vt1vuR9QcGYFDyaJY3mb6/ctM7ojyZhy7Jk8nT en6515RdHA7rjR5IjGuofRrEsBCPccBO04y2bmwo68yOth6N7qWkw0XxDfw6iW5y v2tfM3SUYxATz6OoGYpXai75RRUa4xPKBdrO0/i7c4iBcYlmboLqO/NcmCJ8fYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=k3f5QU u7mYVqp7ULmn+Gimlg+jF1QaVuZfdoYL8h+mrShE0irTMEWHhGhVW78oi3K5IOOo kR1PJqXL5HxTeNFbx646kulMpw4Sc2hzDKxCAlKCBpunxxs+Lceui2SEnbZzXsBZ LrlsSM+WsPW4TD5Iwi3QR3IHmBQHiURe0QClQ= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5A5217F1DB for ; Fri, 13 Nov 2009 14:50:59 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id ED1417F1DA for ; Fri, 13 Nov 2009 14:50:58 -0500 (EST) Message-ID: <4AFDB8DF.4010608@pobox.com> Date: Fri, 13 Nov 2009 11:51:59 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AFC5D80.2030101@pobox.com> <4AFD91D1.7030409@pobox.com> In-Reply-To: <4AFD91D1.7030409@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: DD8809E8-D08D-11DE-B243-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] Two Opaque Values in Renegotiation_Info (was Re: webex) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 19:50:31 -0000 I forgot to change the Subject line.... Michael D'Errico wrote: >> the jabber logs are available here >> http://www.ietf.org/jabber/logs/tls/2009-11-12.txt > > I noticed in the logs that there was discussion of wanting to > have two separate opaque values, I assume one for the client > verify data and the other for the server verify data. > > What is the status of this change? > > Mike From Nicolas.Williams@sun.com Fri Nov 13 12:41:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47EC3A67C0 for ; Fri, 13 Nov 2009 12:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, 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 Qno7uCXniDmB for ; Fri, 13 Nov 2009 12:41:55 -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 A20EA3A6783 for ; Fri, 13 Nov 2009 12:41:55 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nADKgOpO015228 for ; Fri, 13 Nov 2009 20:42:24 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 nADKgONS021091 for ; Fri, 13 Nov 2009 13:42:24 -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 nADKNHvD019438; Fri, 13 Nov 2009 14:23:17 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nADKNGdl019437; Fri, 13 Nov 2009 14:23:16 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 13 Nov 2009 14:23:16 -0600 From: Nicolas Williams To: Robert Dugal Message-ID: <20091113202316.GZ1105@Sun.COM> References: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 20:41:56 -0000 On Fri, Nov 13, 2009 at 02:28:53PM -0500, Robert Dugal wrote: > A co-worker an I have been discussing the draft and have some concerns > about sending client and server verify_data in the extension. > > In the ClientHello, the client sends the verify_data from the client's > previous Finish message as the renegotiated_connection data. > > In the ServerHello, the server sends both the cient's verify_data and > the server's verify_data. > > This data is not normally sent in the clear and I am wondering if this > will provide additional data that can be used to mount some other form > of attack . See: draft-altman-tls-channel-bindings-07.txt which addresses your concern. > The only reason we are sending any data at all is to prove that the > renegotiation is bound to a previous handshake, so why not bind it with > some data that is on the wire and visible to everyone? One of my counter-proposals, which I ask to be considered if the use of extensions is problematic for interop reasons, is to add the outer/old connection's client Finished message as one more input in the inner/new connection's Finished message verify_data computation (see post to tls@ietf.org with message-ID <20091113005419.GQ1105@Sun.COM>. The rationale for that proposal is not that Finished message verify_data is sensitive (it is not), but that the use of extensions may be harmful to interop (and if that's not the case, then that proposal is to be ignored). > One possability is to use the client and server randoms as the > renegotiated_connection data. This data is sent as plaintext on the > wire so it reveals nothing the attacker doesn't already know. I explained why that doesn't work in a post with message-ID <20091105171308.GY1105@Sun.COM> posted on Thu, 5 Nov 2009 11:13:08 -0600 (subject: Re: [TLS] TLS renegotiation issue). > Another alternative could be to use the client's encrypted Finish > message rather than the verify_data from Client's Finish message, and > server's encrypted Finish message. See: draft-altman-tls-channel-bindings-07.txt Nico -- From ynir@checkpoint.com Fri Nov 13 13:40:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E23F3A6A37 for ; Fri, 13 Nov 2009 13:40:06 -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 mmcR45DtFA+C for ; Fri, 13 Nov 2009 13:40:05 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D44C23A69B1 for ; Fri, 13 Nov 2009 13:40:04 -0800 (PST) X-CheckPoint: {4AFDCF15-3-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id AEDBD29C005; Fri, 13 Nov 2009 23:40:34 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 95EA829C002; Fri, 13 Nov 2009 23:40:34 +0200 (IST) X-CheckPoint: {4AFDCF15-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nADLeXc6012963; Fri, 13 Nov 2009 23:40:34 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 13 Nov 2009 23:40:39 +0200 From: Yoav Nir To: "Michael D'Errico" , "tls@ietf.org" Date: Fri, 13 Nov 2009 23:37:03 +0200 Thread-Topic: [TLS] assert TLSext in renego-ServerHello instead of disable renego Thread-Index: Acpke8UNNjSEmMboS4eBCZfkMfMJfwALat+d Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EC024@il-ex01.ad.checkpoint.com> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com>, <4AFD850C.7010704@pobox.com> In-Reply-To: <4AFD850C.7010704@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 21:40:06 -0000 Actually, there have been messages suggesting that clients sending this (or= any other) extension, may have their session terminated, especially if usi= ng SSLv3 and even with some TLS 1.0 servers. If that is true for even a sma= ll minority of servers (say, 1%) we can't realistically expect browser vend= ors to add this, except buried deeply in some advanced menu. I wish we had some hard data on this, but if this is true, we may need to f= ind other ways for the client to signal support, or to signal re-negotiatio= n. ________________________________________ From: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Michael D'Er= rico [mike-list@pobox.com] Sent: Friday, November 13, 2009 18:10 To: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable r= enego >> My point was that if the server *is* upgraded and the client does not >> send the extension on its initial handshake, it is taking an unnecessary >> risk. > > The issue isn't whether the client sends it. Of course the client > sends it. It's whether the client aborts the connection of the server > doesn't return it. I'm in agreement with you that the client should send the extension. But there have been messages suggesting that a client doesn't need to send it on its initial connection, only when renegotiating. I've been trying to convince them that the client must send it especially in its first handshak= e in order to avoid being attacked. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls= From mrex@sap.com Fri Nov 13 14:23:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42753A69A6 for ; Fri, 13 Nov 2009 14:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 GGI0AwP9UAs2 for ; Fri, 13 Nov 2009 14:23:24 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id C91AD3A6952 for ; Fri, 13 Nov 2009 14:23:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nADMNoAB004123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2009 23:23:50 +0100 (MET) From: Martin Rex Message-Id: <200911132223.nADMNo52013257@fs4113.wdf.sap.corp> To: rdugal@certicom.com (Robert Dugal) Date: Fri, 13 Nov 2009 23:23:50 +0100 (MET) In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> from "Robert Dugal" at Nov 13, 9 02:28:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] client and server verify_data in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 22:23:24 -0000 Robert Dugal wrote: > > A co-worker an I have been discussing the draft and have some concerns > about sending client and server verify_data in the extension. > > This data is not normally sent in the clear and I am wondering if this > will provide additional data that can be used to mount some other form > of attack. This particular issue is a misunderstanding of how this extension works. The TLS Renegotiation_Info contains the verify_data of the client.finished (ExtendedClientHello) and client.finished | server.finished (ExtendedServerHello) _ONLY_ on the renegotiation handshake, which happens under the protection of the active TLS session. The very same verify_data was actually transferred under exactly this same protection as the very first message. As described in my recent proposal, it is not necessary to send this data at all. Just devise a different instruction to have TLS at either end include its local copy of this previous handshake verify_data in the handshake message hash that goes into the Finished calculation of the new handshake (as well as the VerifyCertificate calculation when client-cert is used) and you get the same effect with respect to including the previous session in the authentication of the new session. -Martin From lists@drh-consultancy.demon.co.uk Fri Nov 13 14:58:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980353A67AA for ; Fri, 13 Nov 2009 14:58:37 -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 vwIWKmChRR0C for ; Fri, 13 Nov 2009 14:58:36 -0800 (PST) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by core3.amsl.com (Postfix) with ESMTP id 609493A659C for ; Fri, 13 Nov 2009 14:58:36 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49865 helo=[192.168.7.8]) by relay05.mail.eu.clara.net (relay.clara.net [213.253.3.45]:10587) with esmtpa (authdaemon_plain:drh) id 1N956d-00076D-Ig (Exim 4.69) for tls@ietf.org (return-path ); Fri, 13 Nov 2009 22:59:04 +0000 Message-ID: <4AFDE4C0.9090007@drh-consultancy.demon.co.uk> Date: Fri, 13 Nov 2009 22:59:12 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com>, <4AFD850C.7010704@pobox.com> <006FEB08D9C6444AB014105C9AEB133FB36A4EC024@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EC024@il-ex01.ad.checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 22:58:37 -0000 Yoav Nir wrote: > Actually, there have been messages suggesting that clients sending this (or any other) extension, may have their session terminated, especially if using SSLv3 and even with some TLS 1.0 servers. If that is true for even a small minority of servers (say, 1%) we can't realistically expect browser vendors to add this, except buried deeply in some advanced menu. > > I wish we had some hard data on this, but if this is true, we may need to find other ways for the client to signal support, or to signal re-negotiation. After OpenSSL enabled TLS extensions by default it initially included them in SSLv3 client hello's too. We did have quite a few reports of problems so this was disabled in the latest snapshots. Anything using an SSLv3 compatible client hello (i.e. says it supports TLSv1 or later but will also accept SSLv3) has the same potential problem and the deprecated SSLv2 compatible client hello is of course a non-starter. Not sure if this has been mentioned before but a dummy ciphersuite should be acceptable to any server. That is we allocate one unused ciphersuite to have the special meaning of "client supports renegotiation extension". Those so inclined could include it in an SSLv2 compatible client hello too. How a server signals support then becomes a problem. You can't send back an extension in the server hello without violating the protocol rules as they currently stand. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From ekr@networkresonance.com Fri Nov 13 15:06:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A5D3A680B for ; Fri, 13 Nov 2009 15:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naD7CEyKmD4u for ; Fri, 13 Nov 2009 15:06:41 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 878793A67AC for ; Fri, 13 Nov 2009 15:06:41 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N95EV-0001Il-00 for tls@ietf.org; Sat, 14 Nov 2009 01:07:11 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 753DB69F515; Sat, 14 Nov 2009 01:08:16 +0200 (EET) Date: Sat, 14 Nov 2009 01:08:16 +0200 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20091113164608.GT1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091113230816.753DB69F515@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 23:06:42 -0000 At Fri, 13 Nov 2009 10:46:09 -0600, Nicolas Williams wrote: > > On Fri, Nov 13, 2009 at 10:22:35AM +0200, Eric Rescorla wrote: > > At Thu, 12 Nov 2009 14:38:47 -0600, > Nicolas Williams wrote: > > > Interestingly, that approach could even be used on initial connections > > > to detect if the server will support secure re-negotiation _before_ the > > > client ever tries it. > > > > I don't see that. AFAICT both your options involve the client generating a > > hello extension, so this does affect the bits on the wire. Obviously > > there are approaches which don't require that, but they don't provide > > detection of server capabilities on initial negotiation. By contrast > > your message of 1854 doesn't allow the client to probe the server > > AFAICT. > > The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject > "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 > yesterday most certainly described no Hello extensions, only a Finished > message verify_data computation change. Yes, and it doesn't allow you to probe in a compatible way. -Ekr From ekr@networkresonance.com Fri Nov 13 15:08:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D193A682C for ; Fri, 13 Nov 2009 15:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.07 X-Spam-Level: X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Apu6y0+wfwos for ; Fri, 13 Nov 2009 15:08:38 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 096CE3A6822 for ; Fri, 13 Nov 2009 15:08:38 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N95GO-00029s-00 for tls@ietf.org; Sat, 14 Nov 2009 01:09:08 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 8676669F516; Sat, 14 Nov 2009 01:10:13 +0200 (EET) Date: Sat, 14 Nov 2009 01:10:13 +0200 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4AFDB8DF.4010608@pobox.com> References: <4AFC5D80.2030101@pobox.com> <4AFD91D1.7030409@pobox.com> <4AFDB8DF.4010608@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091113231013.8676669F516@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Two Opaque Values in Renegotiation_Info (was Re: webex) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 23:08:38 -0000 At Fri, 13 Nov 2009 11:51:59 -0800, Michael D'Errico wrote: > I forgot to change the Subject line.... As far as I know this is not being actively considered. -Ekr From ekr@networkresonance.com Fri Nov 13 15:09:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0406C3A6822 for ; Fri, 13 Nov 2009 15:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Xg6TW7LjtWp for ; Fri, 13 Nov 2009 15:09:35 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 22C893A6831 for ; Fri, 13 Nov 2009 15:09:35 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N95HI-0002Hh-00 for tls@ietf.org; Sat, 14 Nov 2009 01:10:04 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 5AFFE69F517; Sat, 14 Nov 2009 01:11:10 +0200 (EET) Date: Sat, 14 Nov 2009 01:11:10 +0200 From: Eric Rescorla To: "Robert Dugal" In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> References: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091113231110.5AFFE69F517@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 23:09:36 -0000 At Fri, 13 Nov 2009 14:28:53 -0500, Robert Dugal wrote: > > [1 ] > [1.1 ] > A co-worker an I have been discussing the draft and have some concerns > about sending client and server verify_data in the extension. > > In the ClientHello, the client sends the verify_data from the client's > previous Finish message as the renegotiated_connection data. > > In the ServerHello, the server sends both the cient's verify_data and > the server's verify_data. > > This data is not normally sent in the clear and I am wondering if this > will provide additional data that can be used to mount some other form > of attack . But they're not being sent in the clear here either. They're being sent over the same encrypted channel that they were originally sent over. Remember that you're renegotiating over an existing TLS channel. -Ekr From mrex@sap.com Fri Nov 13 17:05:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC673A68AF for ; Fri, 13 Nov 2009 17:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 xrDtDH5LtSdH for ; Fri, 13 Nov 2009 17:05:07 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E4A273A6830 for ; Fri, 13 Nov 2009 17:05:06 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAE15XPv024412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Nov 2009 02:05:33 +0100 (MET) From: Martin Rex Message-Id: <200911140105.nAE15WLj026261@fs4113.wdf.sap.corp> To: noskov@microsoft.com (Nasko Oskov) Date: Sat, 14 Nov 2009 02:05:32 +0100 (MET) In-Reply-To: from "Nasko Oskov" at Nov 13, 9 07:00:41 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 01:05:08 -0000 Nasko Oskov wrote: > > Martin Rex wrote: > > > > I have never used schannel myself (and haven't found programming > > examples yet). Nasko helpfully pointed me to Sample Code in the Microsoft PlatformSDK (there is a WebServer and WebClient in Samples\Security\SSPI\SSL) There is a difference between IETF GSS-API an Microsoft SSPI here. In GSS-API, it is not possible to restart negotiation on an established security context (handle). As Nasko explained to me, it is possible to restart a handshake on an existing security context handle in Microsoft SSPI (schannel SSP). So the transfer of state from the current TLS session to the newly renegotiated one does not require code changes above SSPI. > > > > > Nico also mentioned, that with SSPI, the renegotiation context > > uses a different/seperate context handle that the original context. > > That is not entirely true. > > It is the return codes from the different APIs that tell you whether > you should go back go negotiation or not. The application itself should > never look at the actual packets and make decisions on their own. > > The way it works is that message protection/unprotection returns > a special error code instructing the application to start handshaking > again, using the same context. > > If a client wants to renegotiate, they just call the proper API with > the current context, which emits renegotiation and handshaking begins. Thanks for that clarification, Nasko. I'm sorry. I got somewhat confused by Nicos comments on SSPI. -Martin From djhopwood@googlemail.com Fri Nov 13 18:20:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1AD3A6926 for ; Fri, 13 Nov 2009 18:20:44 -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 Rh85splCOGCu for ; Fri, 13 Nov 2009 18:20:44 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id BDB653A6808 for ; Fri, 13 Nov 2009 18:20:43 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1144361eyd.51 for ; Fri, 13 Nov 2009 18:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=R0VA7WX+R7h/jeodxPYWeL2izHBSDql4dC17daiuSn0=; b=jjIi0rfQC9PtyL8yUY62CFZWBZwZvbXClSp7byDU4ZclpNYrnsms0ArWz1q5KamGnL 6GlepF71rbAW/YLdnxHpyBctenCneLkM44He90kGDgdbFBto+zxkGOQtxiIkEMk2C7IY 4Y7axjul10M+uGLJqb99EbjlH8ai8TVyy1F6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=KN8/A+4xzFwGIOpJGPd3HdCxQR0cPqiXOvVwlWYLfKvGy7NgmqVN9najxpzD6mjFXm E5kmLtv+3D8wXzmE2NXCGylcT/kOJVn3o3RqkmZvYfkb/I8HnpjIk2mXMtO7FbdGyliH aAtOL7w0eLek/1azlxt/jzTe/ZbKoeQvHh6LI= Received: by 10.213.100.65 with SMTP id x1mr3376130ebn.67.1258165270054; Fri, 13 Nov 2009 18:21:10 -0800 (PST) Received: from ?192.168.0.2? (5e06f2bf.bb.sky.com [94.6.242.191]) by mx.google.com with ESMTPS id 7sm1436813eyg.17.2009.11.13.18.21.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 18:21:09 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFE1408.9040706@jacaranda.org> Date: Sat, 14 Nov 2009 02:20:56 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> In-Reply-To: <20091113005419.GQ1105@Sun.COM> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1AB9B9912EDA782A24F95CFD" Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 02:20:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1AB9B9912EDA782A24F95CFD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > Comments: >=20 > 1) The rest of this comment can be ignored if the use of protocol > extensions in draft-rescorla-tls-renegotiate is deemed to not be a > problem. >=20 > I believe this problem can be fixed without using protocol extension= s > at all. All that has to be done is this: for re-negotiations the > Finished message computation changes from this: >=20 > PRF(master_secret, finished_label, Hash(handshake_messages)) > [0..verify_data_length-1]; >=20 > to: >=20 > PRF(master_secret, finished_label, > Hash(handshake_messages || outer_connection_client_finished)) > [0..verify_data_length-1]; >=20 > where outer_connection_client_finished is the client Finished messag= e > for the previous/old/outer TLS connection >=20 > There is no need to signal this! The problem is that this unnecessarily breaks cases in which the possibility of attack couldn't have been prevented (because only one of the client and server supports the extension), and in which there may actually be no attack. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig1AB9B9912EDA782A24F95CFD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr+FBIACgkQWUc8YzyzqAcRRgD/VsXc4vpzAZWHAdN7jLzMn/yb S1dWSAdgqCXR20mf/+cA/2MOeGVnlDK3N8KiND5eeFkj6scwzi58wt15DRJjEjFL =6y7G -----END PGP SIGNATURE----- --------------enig1AB9B9912EDA782A24F95CFD-- From djhopwood@googlemail.com Fri Nov 13 18:38:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38753A68F8 for ; Fri, 13 Nov 2009 18:38:06 -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 mJFQDMwYWWlW for ; Fri, 13 Nov 2009 18:38:06 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id B8ED63A681A for ; Fri, 13 Nov 2009 18:38:05 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1148280eyd.51 for ; Fri, 13 Nov 2009 18:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=eUMHPYFQxN3fYwBEmrW3hnH48ms1RNKE27tXb7e8/zE=; b=FfacqixrDmZLRYAuT4N9aLcSimj28k5MJuYet0rgYllYFt5eGqFqCZaH9XH7ga7lLl 2LZ7HjpT7exqx6XojTdbREobBT8g1Emf0oDWgoDk2Kij9bnhzA2MOnqwhEot4689TnZK GIwraYe7DnE72cKnrT1jzZulKAxr1/xzFKYQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=qel+s1U1MA3bYO/1V4sPplrRKKB3UW38q32vCv/fF5QcKXcxj+WR7sqmlCj/ZzMigh AT66dGN0E8v3Dk1bvMd9mwKkxfGat035gLiFJZpi57d4m/tRTUqavzGTOGTBaeqOfYL3 h6ky5EKPL5RJC2syxMLBO101CQ2i8EeVBx3+4= Received: by 10.213.100.168 with SMTP id y40mr546853ebn.28.1258166312642; Fri, 13 Nov 2009 18:38:32 -0800 (PST) Received: from ?192.168.0.2? (5e06f2bf.bb.sky.com [94.6.242.191]) by mx.google.com with ESMTPS id 7sm1599119eyg.41.2009.11.13.18.38.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 18:38:31 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFE181B.2050502@jacaranda.org> Date: Sat, 14 Nov 2009 02:38:19 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig6F099B361E2DDABB0F1FFBB1" Subject: Re: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 02:38:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F099B361E2DDABB0F1FFBB1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert Dugal wrote: > A co-worker an I have been discussing the draft and have some concerns > about sending client and server verify_data in the extension. >=20 > In the ClientHello, the client sends the verify_data from the client's > previous Finish message as the renegotiated_connection data. >=20 > In the ServerHello, the server sends both the cient's verify_data and > the server's verify_data. >=20 > This data is not normally sent in the clear and I am wondering if this > will provide additional data that can be used to mount some other form > of attack . I can't see a feasible attack as long as the hash function doesn't reveal information about its input. However, I think you're right to be concerned; we need input from experienced cryptographers about this. > The only reason we are sending any data at all is to prove that the > renegotiation is bound to a previous handshake, so why not bind it with= > some data that is on the wire and visible to everyone? >=20 > =20 >=20 > One possability is to use the client and server randoms as the > renegotiated_connection data. This data is sent as plaintext on the > wire so it reveals nothing the attacker doesn't already know. That doesn't have the same security properties. It is possible for two different sessions to have the same (ClientRandom, ServerRandom) pair. (Attacker acts as a MITM and forwards client's random to server and vice-versa.) The Finished hashes, OTOH, are unique to a session because an attacker can't force the whole handshake to be identical for two sessions (well, unless they are talking to themself). > Another alternative could be to use the client's encrypted Finish > message rather than the verify_data from Client's Finish message, and > server's encrypted Finish message. That would work. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig6F099B361E2DDABB0F1FFBB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr+GCMACgkQWUc8YzyzqAf7FAD+P48XNMPYRqnXYv+/pgpVAODL P8H5GrdI0mJDzP2zb4oA/jDP5CFzS5DVED6ovmEvEgNrdejb3e1K0sSqyHqZw4n4 =oKkb -----END PGP SIGNATURE----- --------------enig6F099B361E2DDABB0F1FFBB1-- From djhopwood@googlemail.com Fri Nov 13 18:44:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AECD63A68BF for ; Fri, 13 Nov 2009 18:44:19 -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 4PuFMaZl1UhX for ; Fri, 13 Nov 2009 18:44:19 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id AD8D93A67EF for ; Fri, 13 Nov 2009 18:44:18 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1149736eyd.51 for ; Fri, 13 Nov 2009 18:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=gwZi1yBEn14T5RJhUTFABJIWXfowN+9chs4/E2Fg5ps=; b=cceaqonMgKw2oAhgvOqq6/5nCYuT4Ufc6E6eANlmnPpRoqUVCfIhleiFO4C+pkf3fN HDmISh+7ZGhlqjP80zBs1i2DhYz8Nhdk9JjKriYzkVKp9aPln38/xuLhYvkayjNFLfYY u0egmYZvDlaD08nJSKh9iUqVDozmxOxO4RnEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=G17RkKBI00QEBBQTXiT8pfJsWVx9f01n6+vxDWw2TeJU8E+GViJQdmcx4J+4LAKmmF hul9SlSq7ajsz9DpEczdtyqyAmnrGikT3rYGklmR83vFLMbf3QXWcGZSDSO0hL6GOMUg PF1J3hDcpiZuqOuk/qLplA1rsSVa/tlFuTVUk= Received: by 10.213.2.70 with SMTP id 6mr539115ebi.25.1258166685328; Fri, 13 Nov 2009 18:44:45 -0800 (PST) Received: from ?192.168.0.2? (5e06f2bf.bb.sky.com [94.6.242.191]) by mx.google.com with ESMTPS id 7sm2323674eyg.9.2009.11.13.18.44.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 18:44:44 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFE1999.1080806@jacaranda.org> Date: Sat, 14 Nov 2009 02:44:41 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net> <4AFE181B.2050502@jacaranda.org> In-Reply-To: <4AFE181B.2050502@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5FD2364324566B9E5FFDB640" Subject: Re: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 02:44:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5FD2364324566B9E5FFDB640 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Robert Dugal wrote: >> A co-worker an I have been discussing the draft and have some concerns= >> about sending client and server verify_data in the extension. >> >> In the ClientHello, the client sends the verify_data from the client's= >> previous Finish message as the renegotiated_connection data. >> >> In the ServerHello, the server sends both the cient's verify_data and >> the server's verify_data. >> >> This data is not normally sent in the clear and I am wondering if this= >> will provide additional data that can be used to mount some other form= >> of attack . >=20 > I can't see a feasible attack as long as the hash function doesn't > reveal information about its input. However, I think you're right to > be concerned; we need input from experienced cryptographers about this.= Actually this is definitely fine, because the verify_data will be encrypted if the preceding session was not controlled by the attacker (and if it was, then the attacker knows the verify_data anyway). --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig5FD2364324566B9E5FFDB640 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr+GZoACgkQWUc8YzyzqAc47QEAi90Q8OTI2bZ2xqXL07Uso1MK ph6xmb+21Gm2cSrKvbMBAICk1QSii80StQFsyn2yOAuNlr10TcaTSdl0sR2GPTK9 =RVNb -----END PGP SIGNATURE----- --------------enig5FD2364324566B9E5FFDB640-- From djhopwood@googlemail.com Fri Nov 13 21:30:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D383A6929 for ; Fri, 13 Nov 2009 21:30:43 -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 dTDKyxrL2Up6 for ; Fri, 13 Nov 2009 21:30:42 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 07A293A67F2 for ; Fri, 13 Nov 2009 21:30:41 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1186867eyd.51 for ; Fri, 13 Nov 2009 21:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=SmO3miWTj+gBqnn6HbKMg/crf4/qpOUwwhbwQci9Kz0=; b=eY3j4h8God7CBU3b4TS++k7EKXG5P5e/zlBE3hQx1GPhOIscTMqKYNg4VHorg6Nb8d FtmFn0G4Aqhus5tVSUkNbCcifQuGiR44k0bWOVZl5PQ9bhSz2TsdGWCaq6A4PFmg3h/E i6XZkG7eNVvQNH2hl79b/m/5MoBmuyh7fQ3W8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=cL6c+qyfMQ6wK7M/WRwAcA/WTjWc0g5umCsUeytUAjsaCnceqxa+8NgiX36mZRHobq owIEECKEUn7a7ZHjjnCpXCmdzEyd26jykkPHKx7EBWdINZSvI6WC8LxEDsmx1LM3+2sM 9g76ycRKyOJm4aA5hid10UATvm81RFaBzN7tk= Received: by 10.213.63.14 with SMTP id z14mr593196ebh.17.1258176669189; Fri, 13 Nov 2009 21:31:09 -0800 (PST) Received: from ?192.168.0.2? (5add95c7.bb.sky.com [90.221.149.199]) by mx.google.com with ESMTPS id 28sm1787340eyg.30.2009.11.13.21.31.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 21:31:08 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFE4091.10005@jacaranda.org> Date: Sat, 14 Nov 2009 05:30:57 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> In-Reply-To: <4AFE1408.9040706@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2CBC45733CD3661485B0E499" Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 05:30:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2CBC45733CD3661485B0E499 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Nicolas Williams wrote: >> Comments: >> >> 1) The rest of this comment can be ignored if the use of protocol >> extensions in draft-rescorla-tls-renegotiate is deemed to not be a >> problem. >> >> I believe this problem can be fixed without using protocol extensio= ns >> at all. All that has to be done is this: for re-negotiations the >> Finished message computation changes from this: >> >> PRF(master_secret, finished_label, Hash(handshake_messages)) >> [0..verify_data_length-1]; >> >> to: >> >> PRF(master_secret, finished_label, >> Hash(handshake_messages || outer_connection_client_finished)) >> [0..verify_data_length-1]; >> >> where outer_connection_client_finished is the client Finished messa= ge >> for the previous/old/outer TLS connection >> >> There is no need to signal this! >=20 > The problem is that this unnecessarily breaks cases in which the > possibility of attack couldn't have been prevented (because only > one of the client and server supports the extension), and in which > there may actually be no attack. No, on further consideration this argument is wrong. Since adding the verify_data into the Finished hashes would only happen for renegotiations= , it cannot cause any interoperability failures on an initial handshake. It would cause a handshake failure on a renegotiation, if only the client= or only the server has been patched. Note that a handshake failure in that case doesn't necessarily result in an interoperability failure. That's because many clients will fall back to reconnecting on a new session, if a renegotiation fails. In fact, implementors of web browser clients essentially have no choice but to do this if they want to interoperate with many web servers (the situation= might be different for non-HTTP protocols) [*]. On the other hand, consider the case of a patched client performing an initial handshake with an unpatched server. If an extension is not used, then there is no way for the client to tell that the server is unpatched,= and the connection might succeed even though an attack is taking place. Using the extension would give patched clients the option of refusing to connect to unpatched servers. The converse situation, where a patched server does not know whether it is talking to a patched or unpatched client, is probably less significant= : an attack can only succeed in that case if the client does not check the server's certificate, in which case a MITM attack is possible anyway. Important point: TLS- or extension-intolerant servers are all unpatched. If a client implementor considers it necessary to interoperate with such servers, then that would not be consistent with a policy of refusing= to connect to unpatched servers. Suppose that we only use an extension as an advisory of patched status (i.e. say that an empty extension SHOULD= be sent if patched), but add the verify_data into the Finished hashes unconditionally (i.e. as a MUST) for renegotiating handshakes. Then, the concerns about extensions potentially breaking some servers, and the concerns about lack of an extension potentially resulting in a security weakness (due to a client being unable to tell whether a server is patche= d), would only arise in mutually exclusive sets of cases. [*] There is a corner case in which this argument might not apply -- the "Step-Up" protocol, where old versions of the Netscape browser would initially offer only 40-bit ciphersuites, and then renegotiate to use a stronger ciphersuite if they see that a bit is set in the certificate. Such browsers are obviously unpatched, and will fail to renegotiate with a patched server that is using a Step-Up certificate= =2E Note that "Step-Up" is different from "Server-Gated Cryptography" (SGC), in which the client never completes the first handshake and reconnects in a new session: SGC does not rely on renegotiation. (Verisign/Thawte sells certs that support both and does not distinguish between them; don't be confused by that.) Step-Up was a Netscape proposal, and SGC was from Microsoft. I don't think that Internet Explorer ever implemented Step-Up (as opposed to SGC). Netscape only implemented it in versions 3.x and 4.x, which have numerous arbitrary code execution bugs that would be easier to exploit. So this is not a significant issue at all -- any sites that are still using Step-Up certs, would be well advised to just patch their servers and tell their users to stop using such old browser versions. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig2CBC45733CD3661485B0E499 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr+QJgACgkQWUc8YzyzqAd5zgD+K/HJugaB9lQFxObKC9z0UJ0B 05coW1ce8WRYuYrjsZgA/0daw3oSuNTrTRsQ7n19SLynhjeLSfs57wNp+VZpAgZI =oA7/ -----END PGP SIGNATURE----- --------------enig2CBC45733CD3661485B0E499-- From djhopwood@googlemail.com Fri Nov 13 23:04:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A1A3A6826 for ; Fri, 13 Nov 2009 23:04:11 -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 hFHv4skb5rGh for ; Fri, 13 Nov 2009 23:04:10 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 158AD3A681B for ; Fri, 13 Nov 2009 23:04:09 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1207962eyd.51 for ; Fri, 13 Nov 2009 23:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=jlQcez48oBUR/034X2pO4TaJjlJKEFGWW/3k2SS5NXI=; b=ET5VTGPVFZ+1/iHYPs80vWttjdneBMoNcCznXF6JpQiUeWdkRbRYu6yBqEoGUXyP/k ePEOwPTetstHZGDcEDkRTzPaxq4DuFqjk0jn6Qp+pU8yKWbuRZ4g8/qtVUej8ieRAbrL Z+aK2Tb6zfHB72w7c3QOqE77sHNA3hyAMy72s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=WQbqHzcFdYgqLOQZTT4l2s0gtWO1zmeJJ0NGuEwf467u3TU4re+QgyuUG/hX+lv+EQ HSWwNYVWN61axQ9zoOUXX2qEQFqlfJvUctBFzmjpFEjZq0gBjkLzRaynbjCkpFojJUX1 foeDI1y4658NlYpb31p3V6vdVI5XYcuGHa3mg= Received: by 10.213.23.199 with SMTP id s7mr3362814ebb.80.1258182277254; Fri, 13 Nov 2009 23:04:37 -0800 (PST) Received: from ?192.168.0.2? (5add95c7.bb.sky.com [90.221.149.199]) by mx.google.com with ESMTPS id 10sm2549545eyd.7.2009.11.13.23.04.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 23:04:36 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFE5673.9080101@jacaranda.org> Date: Sat, 14 Nov 2009 07:04:19 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <4AFE4091.10005@jacaranda.org> In-Reply-To: <4AFE4091.10005@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig38119453F46A2BEF39865243" Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 07:04:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38119453F46A2BEF39865243 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > On the other hand, consider the case of a patched client performing an > initial handshake with an unpatched server. If an extension is not used= , > then there is no way for the client to tell that the server is unpatche= d, > and the connection might succeed even though an attack is taking place.= > Using the extension would give patched clients the option of refusing t= o > connect to unpatched servers. >=20 > The converse situation, where a patched server does not know whether it= > is talking to a patched or unpatched client, is probably less significa= nt: > an attack can only succeed in that case if the client does not check th= e > server's certificate, in which case a MITM attack is possible anyway. Ah, but *if* the unpatched client does not properly check the certificate= , then the attack that is described here by Martin Rex: would be possible only as a result of the renegotiation flaw; it is not possible just using an ordinary MITM attack. More specifically, the difference between this and an ordinary MITM is that in the latter, the attacker cannot *both* control a prefix of the session, and cause the server to be convinced that the client is authenticated by a particular client cert. The problem here is that if the server does not see the extension in the ClientHello, and it chooses to break the connection in order to avoid the= possibility of the above attack, then it might be unnecessarily breaking a connection with a patched client that was just unwilling to send the extension. Still, that's no worse than the situation with the current draft-rescorla-tls-renegotiate. So I think that what I suggested: > [...] only use an extension > as an advisory of patched status (i.e. say that an empty extension SHOU= LD > be sent if patched), but add the verify_data into the Finished hashes > unconditionally (i.e. as a MUST) for renegotiating handshakes. Then, th= e > concerns about extensions potentially breaking some servers, and the > concerns about lack of an extension potentially resulting in a security= > weakness (due to a client being unable to tell whether a server is patc= hed), > would only arise in mutually exclusive sets of cases. is still an overall improvement. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig38119453F46A2BEF39865243 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr+VoAACgkQWUc8YzyzqAcKswEAgEFttsSdCBZV79I094zo2kIG CwtsjZuPPPi8EW2HsZgA+wdxWyjmj0TkSXLHeakOO0Q4JhrTahFi4bZU9OimzP2o =gl3c -----END PGP SIGNATURE----- --------------enig38119453F46A2BEF39865243-- From ekr@networkresonance.com Fri Nov 13 23:40:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4293A689C for ; Fri, 13 Nov 2009 23:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gyYR5r8xxKK for ; Fri, 13 Nov 2009 23:40:00 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 167A03A6819 for ; Fri, 13 Nov 2009 23:40:00 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9DFE-0001cG-00 for tls@ietf.org; Sat, 14 Nov 2009 09:40:28 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3BFB969F59C; Sat, 14 Nov 2009 09:41:35 +0200 (EET) Date: Sat, 14 Nov 2009 09:41:31 +0200 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911131534.nADFYxDa020395@fs4113.wdf.sap.corp> References: <20091113082235.C55F469F381@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091114074136.3BFB969F59C@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Protected Renegotiation -- refined proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 07:40:01 -0000 Martin, I agree that these have similar properties cryptographically, but I don't agree that it is really an improvement overall. As I understand your proposal, the advantage that it offers over RI is that with RI an attacker can simulate an extension processing failure. This leaves the client unable to distinguish between: - A server which does not support RI (and therefore is potentially though not definitely vulnerable to a renegotiation attack) - An attacker who is blocking RI. By contrast, with your proposal the client can reliably distinguish these two, because additional unknown ciphersuites do not cause failures. I have two observations about this: 1. I'm not sure that differentiating these two cases is that interesting. - For the foreseeable future, the majority of servers will not support RI, so clients can't really do anything useful with the information that the server doesn't support it. Remember that implementations which DO support RI really should not be allowing renegotiation without it, in which case if a client is fooled into thinking that the server doesn't do RI, the likely result is that the client can't renegotiate, not an unsafe renegotiation - Non-support of RI is not necessarily an indicator of vulnerability since many servers will simply patch to the point where they don't renegotiate but not add RI support. - Any implementation of SSL/TLS which is so downrev that it cannot properly process extensions most likely has other serious security vulnerabilities so a client which wishes to be careful and not deal with servers which don't support RI should probably not connect to it in any case. IOW, the attacker can just force a paranoid client not to connect at all. 2. If you're interested in differentiating these cases in an unspoofable way, there's a compromise method which doesn't require a covert version upgrade that is signalled by the client in the cipher suite but not in the version number (contrary to the ordinary TLS style). Under ordinary conditions you offer TLS as usual with RI. If you get an error and are forced to fall back to SSLv3 or otherwise remove RI, *then* you signal an additional fake cipher suite whose only semantics are: "I tried to do RI but I was forced to downgrade." Servers which support RI can then simply generate an error if they ever see this cipher suite. [Alternately, you could always include the cipher suite, which makes the client logic simpler and the server logic slightly more complicated because the error becomes conditional.] This design has the advantage that it retains the ordinary TLS extension mechanism as the "main" code path and only uses the fake cipher suite as a fallback to detect inline downgrade. This is very much in the spirit of the existing TLS belt-and-suspenders defenses (e.g., the 030303... padding in the RSA when downgraded to SSL version 2). It also doesn't screw up our versioning scheme if/when we want to do TLS 1.3. As far as I can tell, the major disadvantage vis-a-vis the scheme you propose is that it requires one more pass with servers which don't support extensions, but IMO given that modern browsers now offer SNI, we're beyond the point where we have to be afraid of routinely offering extensions and falling back if necessary. -Ekr At Fri, 13 Nov 2009 16:34:59 +0100 (MET), Martin Rex wrote: > Nico an I are talking about slighty different things. > > I will try to reexplain my most recent mind model of how this should > be solved, and you will see that the cryptographic properties are > almost identical to the TLS extension RI. My most recent model > will actually grow naturally into TLS v1.3 and become invisible. > > The cryptographic concept behind the actual fix: > > I. Initial SSL/TLS Handshake on a connection > > Here we want to achieve three things: > > a) Securely signal from client to server that client is updated > b) Securely signal from server to client that server is updated > (provided that client has indicated that it will understand > this information) > c) Signal that this is an initial handshake so that it can not > be proxied into a renegotiation handshake > > in an abstract fashion, the protocol update looks like this: > > Initial SSL/TLS handshake on a connection > > Traditional: Updated: > > ClientHello ClientHello + ProtocolUpdateIndicatorC2S > ServerHello ServerHello + ProtocolUpdateIndicatorS2C > -- all further handshake messages unchanged --- > > TLS extension RI: > > (1a) + (1c) For the TLS extension RI, the ProtocolUpdateIndicatorC2S > is a ClientHelloExtension "RI" with empty data > > (1b) + (1c) For the TLS extension RI, the ProtocolUpdateIndicatorS2C > is a ServerHelloExtension "RI" with empty data > > Both ProtocolUpdateIndicators have no special cryptographic > properties. They're part of the handshake messages so that > can not be stripped from an MITM without breaking the > MAC-check by the Finished messages. > > My (revised) proposal: > > My proposal is to use two other ProtocolUpdateIndicators > instead that can be added to all existing protocol versions > with significantly less pain an suffering, and in a fully fowards > compatible fashion so that this ProtocolUpdate will grow out > naturally with the next TLS protocol update (TLSv1.3) > > (1a) assign a special ciphersuites ID as ProtocolUpdateIndicatorC2S > that is to be included in the ciphersuites list of the ClientHello > and extremely backwards compatible with installed base servers > that implement SSLv3->TLSv1.2 (0x03,0x00) -> (0x03,0x03). > > (1c) change the computation of the finished mac for all renegotiation > handshakes > > (1b) increase the major number of the protocol version by one as the > ProtocolUpdateIndicatorS2C, which means: > > 0x03,0x00 SSLv3, unpatched 0x04,0x00 SSLv3 patched > 0x03,0x01 TLSv1.0, unpatched 0x04,0x01 TLSv1.0 patched > 0x03,0x02 TLSv1.1, unpatched 0x04,0x02 TLSv1.1 patched > 0x03,0x03 TLSv1.2, unpatched 0x04,0x03 TLSv1.2 patched > > (0x03,0x04 TLSv1.3 only for client_version) > 0x04,0x04 TLSv1.3 > > (1a2) A client that sends a ClientHello with a client_version > that is >=0x03,0x04 also indicates that it will used the > changed computation of finished mac calculation for > the renegotiation handshake. > > > II. Renegotiation SSL/TLS handshake on a connection > > Here we want to achieve: > > a) cryptographic binding of the renegotiation handshake to the > previous session by adding the verify_data of the previous > finished messages as known to the client into the handshake > message hash (->ClientVerify, ->Finished) > > b) cryptographic binding of the renegotiation handshake to the > previous session by adding the verify_data of the previous > finished messages as known to the server into the handshake > message hash (->ClientVerify, ->Finished) > > > Renegotiation SSL/TLS handshake on a connection > > Traditional: Updated: > > ClientHello ClientHello + ClientsPreviousVerifyData > ServerHello ServerHello + ServersPreviousVerifyData > -- all further handshake messages unchanged --- > > TLS extension RI: > > (2a) adds the clients verify_data from previous client.finished > message into ClientHelloExtension RI > > (2b) adds the servers verify_data from previous (client.finished and) > server.finished message into ServerHelloExtension RI > > The Handshake Messages MAC will roughly receive the following data: > > ClientHello > FF 01 00 01 0C > > ServerHello > FF 01 00 01 18 > > > -- all further handshake messages unchanged --- > > > My (revised) proposal: > > (2a)+(2b) effectively change the computation of the finished macs > by redefining what goes into the handshake message hash if the > updated protocol is used. The verify_data of the previous > client.finished and server.finished messages are defined to > be handshake messages that are _not_ sent in the current > handshake (think of it as carryover from the previous handshake). > > The Handshake Messages MAC will roughly receive the following data: > > Client-side: > > ClientHello > ServerHello <> > > -- all further handshake messages unchanged --- > > Server-side: > > ClientHello > ServerHello > > > -- all further handshake messages unchanged --- > > The verify_data should become a "virtual handshake message" > _after_ the ServerHello, when client and server both know > that they're really using the updated protocol. > > To me, it looks like this approach and TLS extension RI are > very similar in their cryptographic properties. > > By adding the verify_data to the handshake message MACs (but > not the message stream) always after ServerHello, they are also <> covered by the clients signature in the ClientVerify message -- > in case that cert-based SSL/TLS client authentication is used. > This property is also similar to TLS extension RI. > > If the clients memories about the previous session differ from > those of the server, the finished messages of the renegotiation > handshake will differ. If client cert authentication is used, > the signature verification of ClientVerify will already fail. > > > > -Martin From Nicolas.Williams@sun.com Sat Nov 14 00:39:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939A83A688E for ; Sat, 14 Nov 2009 00:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, 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 KQ7SBogYNyZl for ; Sat, 14 Nov 2009 00:39:22 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id A772E3A6820 for ; Sat, 14 Nov 2009 00:39:22 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAE8doKF020611 for ; Sat, 14 Nov 2009 08:39:52 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 nAE8dovB039933 for ; Sat, 14 Nov 2009 01:39:50 -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 nAE8SDED019940; Sat, 14 Nov 2009 02:28:13 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAE8SDA2019939; Sat, 14 Nov 2009 02:28:13 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 14 Nov 2009 02:28:13 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091114082813.GD1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <20091113230816.753DB69F515@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091113230816.753DB69F515@kilo.networkresonance.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 08:39:23 -0000 On Sat, Nov 14, 2009 at 01:08:16AM +0200, Eric Rescorla wrote: > At Fri, 13 Nov 2009 10:46:09 -0600, > Nicolas Williams wrote: > > The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject > > "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 > > yesterday most certainly described no Hello extensions, only a Finished > > message verify_data computation change. > > Yes, and it doesn't allow you to probe in a compatible way. No, that's not correct. On initial connection there's no need to do anything special (sure, it's nice to know that your peer doesn't have this vuln, but you don't have to). On re-negotiate you unconditionally want non-vulnerable behavior, thus there's nothing to negotiate, nothing to probe for. It's only when you're willing to re-negotiate in a vulnerable way that you should probe/negotiate. That may be useful as part of a transition strategy. However, if the negotiation itself causes breakage, then it may not be feasible. I repeat: "[this proposal is to] be ingored if the use of protocol extensions in draft-rescorla-tls-renegotiate is deemed to not be a problem". Nico -- From Nicolas.Williams@sun.com Sat Nov 14 00:42:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8D33A6820 for ; Sat, 14 Nov 2009 00:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.025, 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 t+8Q2vkzKO+A for ; Sat, 14 Nov 2009 00:42:41 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 5A6E73A67E5 for ; Sat, 14 Nov 2009 00:42:41 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAE8hCZb021655 for ; Sat, 14 Nov 2009 08:43:12 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 nAE8hBsF040981 for ; Sat, 14 Nov 2009 01:43:12 -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 nAE8VbL4019949; Sat, 14 Nov 2009 02:31:37 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAE8VaX6019948; Sat, 14 Nov 2009 02:31:36 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 14 Nov 2009 02:31:36 -0600 From: Nicolas Williams To: David-Sarah Hopwood Message-ID: <20091114083136.GE1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFE1408.9040706@jacaranda.org> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 08:42:42 -0000 On Sat, Nov 14, 2009 at 02:20:56AM +0000, David-Sarah Hopwood wrote: > Nicolas Williams wrote: > > Comments: > > > > 1) The rest of this comment can be ignored if the use of protocol > > extensions in draft-rescorla-tls-renegotiate is deemed to not be a > > problem. > > > > [...] > > The problem is that this unnecessarily breaks cases in which the > possibility of attack couldn't have been prevented (because only > one of the client and server supports the extension), and in which > there may actually be no attack. That's a feature: for how do you know that "there may actually be no attack"?? Either we fix the vulnerability, or we don't. The only middle of the road is a "ask the user if this is OK" (client-side) or "allow but log" (server-side) temporary transition configuration. Nico -- From Nicolas.Williams@sun.com Sat Nov 14 00:52:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E4A3A682A for ; Sat, 14 Nov 2009 00:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.025, 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 nauoK83U0kwj for ; Sat, 14 Nov 2009 00:52:20 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 293713A6820 for ; Sat, 14 Nov 2009 00:52:20 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAE8qo34024048 for ; Sat, 14 Nov 2009 08:52:50 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 nAE8qo7I006986 for ; Sat, 14 Nov 2009 01:52:50 -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 nAE8fF9V019958; Sat, 14 Nov 2009 02:41:15 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAE8fF5M019957; Sat, 14 Nov 2009 02:41:15 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 14 Nov 2009 02:41:15 -0600 From: Nicolas Williams To: David-Sarah Hopwood Message-ID: <20091114084115.GF1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <4AFE4091.10005@jacaranda.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFE4091.10005@jacaranda.org> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 08:52:21 -0000 On Sat, Nov 14, 2009 at 05:30:57AM +0000, David-Sarah Hopwood wrote: > David-Sarah Hopwood wrote: > > The problem is that this unnecessarily breaks cases in which the > > possibility of attack couldn't have been prevented (because only > > one of the client and server supports the extension), and in which > > there may actually be no attack. > > No, on further consideration this argument is wrong. Since adding the > verify_data into the Finished hashes would only happen for renegotiations, > it cannot cause any interoperability failures on an initial handshake. > It would cause a handshake failure on a renegotiation, if only the client > or only the server has been patched. Right. > Note that a handshake failure in that case doesn't necessarily result in > an interoperability failure. That's because many clients will fall back > to reconnecting on a new session, if a renegotiation fails. In fact, > implementors of web browser clients essentially have no choice but to > do this if they want to interoperate with many web servers (the situation > might be different for non-HTTP protocols) [*]. Right. > On the other hand, consider the case of a patched client performing an > initial handshake with an unpatched server. If an extension is not used, > then there is no way for the client to tell that the server is unpatched, > and the connection might succeed even though an attack is taking place. > Using the extension would give patched clients the option of refusing to > connect to unpatched servers. Irrelevant: nothing that goes over the first connection should be at risk or sensitive, provided that the client did authenticate the server OR, if an anon-anon cipher suite was used, (that the client refrained from sending confidential data AND the client did not take destructive action based on data from the server). It's OK for the client to learn that the server is unpatched when it tries to re-negotiate. > The converse situation, where a patched server does not know whether it > is talking to a patched or unpatched client, is probably less significant: > an attack can only succeed in that case if the client does not check the > server's certificate, in which case a MITM attack is possible anyway. Right. > Important point: TLS- or extension-intolerant servers are all unpatched. Yes. But I get the feeling that some folks think it will be easier to patch them than to upgrade them. My proposal is particularly useful then, since it can be applied even to SSLv3. NOTE: I'm not trying to force a design change at this late stage. I had a caveat at the top of my proposal that it should only be considered if the use of extensions turned out to be problematic. Nico -- From Nicolas.Williams@sun.com Sat Nov 14 00:55:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F9B3A6820 for ; Sat, 14 Nov 2009 00:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.025, 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 G+LwmTmwT30I for ; Sat, 14 Nov 2009 00:55:04 -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 DF3483A67EB for ; Sat, 14 Nov 2009 00:55:03 -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 nAE8tXtw016787 for ; Sat, 14 Nov 2009 08:55: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 nAE8tXPq007683 for ; Sat, 14 Nov 2009 01:55: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 nAE8hxL6019967; Sat, 14 Nov 2009 02:43:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAE8hxBv019966; Sat, 14 Nov 2009 02:43:59 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 14 Nov 2009 02:43:58 -0600 From: Nicolas Williams To: David-Sarah Hopwood Message-ID: <20091114084358.GG1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <4AFE4091.10005@jacaranda.org> <4AFE5673.9080101@jacaranda.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFE5673.9080101@jacaranda.org> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 08:55:04 -0000 On Sat, Nov 14, 2009 at 07:04:19AM +0000, David-Sarah Hopwood wrote: > Still, that's no worse than the situation with the current > draft-rescorla-tls-renegotiate. So I think that what I suggested: > > > [...] only use an extension > > as an advisory of patched status (i.e. say that an empty extension SHOULD > > be sent if patched), but add the verify_data into the Finished hashes > > unconditionally (i.e. as a MUST) for renegotiating handshakes. Then, the > > concerns about extensions potentially breaking some servers, and the > > concerns about lack of an extension potentially resulting in a security > > weakness (due to a client being unable to tell whether a server is patched), > > would only arise in mutually exclusive sets of cases. > > is still an overall improvement. I think that adding to my proposed fix an _optional_ signal in the client's hello (and, correspondingly, in the server hello), would be just fine. I don't believe it's necessary. Nico -- From ekr@networkresonance.com Sat Nov 14 01:03:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0AF3A67DF for ; Sat, 14 Nov 2009 01:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAOeTICVMDhR for ; Sat, 14 Nov 2009 01:03:41 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 407353A67A6 for ; Sat, 14 Nov 2009 01:03:41 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9EYF-0000Bq-00 for tls@ietf.org; Sat, 14 Nov 2009 11:04:11 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 8154569F5C3; Sat, 14 Nov 2009 11:05:19 +0200 (EET) Date: Sat, 14 Nov 2009 11:05:18 +0200 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20091114082813.GD1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <20091113230816.753DB69F515@kilo.networkresonance.com> <20091114082813.GD1105@Sun.COM> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091114090519.8154569F5C3@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 09:03:42 -0000 At Sat, 14 Nov 2009 02:28:13 -0600, Nicolas Williams wrote: > > On Sat, Nov 14, 2009 at 01:08:16AM +0200, Eric Rescorla wrote: > > At Fri, 13 Nov 2009 10:46:09 -0600, > > Nicolas Williams wrote: > > > The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject > > > "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 > > > yesterday most certainly described no Hello extensions, only a Finished > > > message verify_data computation change. > > > > Yes, and it doesn't allow you to probe in a compatible way. > > No, that's not correct. On initial connection there's no need to do > anything special (sure, it's nice to know that your peer doesn't have > this vuln, but you don't have to). Well, I don't know what "have to" means. Some clients may have the policy of not connecting to servers that aren't upgraded. The existing proposal allows that. Yours does not. -Ekr From Nicolas.Williams@sun.com Sat Nov 14 01:32:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E1B3A6930 for ; Sat, 14 Nov 2009 01:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.025, 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 qdLsG2oS8IKr for ; Sat, 14 Nov 2009 01:32:40 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 597673A681E for ; Sat, 14 Nov 2009 01:32:40 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAE9X9aq004930 for ; Sat, 14 Nov 2009 09:33:09 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 nAE9PexU056888 for ; Sat, 14 Nov 2009 02:25:40 -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 nAE9E53l020134; Sat, 14 Nov 2009 03:14:05 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAE9E5lK020133; Sat, 14 Nov 2009 03:14:05 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 14 Nov 2009 03:14:05 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091114091405.GK1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <20091113230816.753DB69F515@kilo.networkresonance.com> <20091114082813.GD1105@Sun.COM> <20091114090519.8154569F5C3@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091114090519.8154569F5C3@kilo.networkresonance.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 09:32:41 -0000 On Sat, Nov 14, 2009 at 11:05:18AM +0200, Eric Rescorla wrote: > At Sat, 14 Nov 2009 02:28:13 -0600, > Nicolas Williams wrote: > > > > On Sat, Nov 14, 2009 at 01:08:16AM +0200, Eric Rescorla wrote: > > > At Fri, 13 Nov 2009 10:46:09 -0600, > > > Nicolas Williams wrote: > > > > The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject > > > > "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 > > > > yesterday most certainly described no Hello extensions, only a Finished > > > > message verify_data computation change. > > > > > > Yes, and it doesn't allow you to probe in a compatible way. > > > > No, that's not correct. On initial connection there's no need to do > > anything special (sure, it's nice to know that your peer doesn't have > > this vuln, but you don't have to). > > Well, I don't know what "have to" means. Some clients may have > the policy of not connecting to servers that aren't upgraded. > The existing proposal allows that. Yours does not. Indeed, though I'm not too concerned by that. For me that is a trade-off to make w.r.t. complications raised by using extensions in the first place (bear with me, please). IIUC the arguments about SSLv3, there's an installed base of SSLv3 and TLS 1.0-with-bugs that is more likely to get patched to fix this and only this than to get upgraded t TLS 1.1+ or to have all their bugs patched. I'm not sure that that's true. IF it is true, then we have to consider the possibility of designing the fix so that it's easier to patch those. In any case, I think it's more important to behave correctly than to also signal that intend to -- the former is required, the latter is a bonus. Nico -- From noskov@microsoft.com Fri Nov 13 11:27:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2E43A68DA for ; Fri, 13 Nov 2009 11:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.191 X-Spam-Level: X-Spam-Status: No, score=-10.191 tagged_above=-999 required=5 tests=[AWL=0.408, 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 cGWkvTgU5F-s for ; Fri, 13 Nov 2009 11:27:41 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id D25F63A677D for ; Fri, 13 Nov 2009 11:27:41 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 13 Nov 2009 11:28:30 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server id 14.0.639.20; Fri, 13 Nov 2009 11:02:02 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 13 Nov 2009 11:02:03 -0800 From: Nasko Oskov To: "mrex@sap.com" , Marsh Ray Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Thread-Index: AQHKZJBMt0TyUbupqEiUlJLepKUMApE0XCYw Date: Fri, 13 Nov 2009 19:00:41 +0000 Deferred-Delivery: Fri, 13 Nov 2009 19:01:00 +0000 Message-ID: References: <4AFB2B42.9060602@extendedsubset.com> from "Marsh Ray" at Nov 11, 9 03:23:14 pm <200911131837.nADIb6GY000472@fs4113.wdf.sap.corp> In-Reply-To: <200911131837.nADIb6GY000472@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 14 Nov 2009 08:36:24 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 19:27:42 -0000 Martin Rex wrote: >Marsh Ray wrote: >>=20 >> Well, if the remote endpoint allows you to initiate a renegotiation.=20 >> MS IIS for example responds with a TCP RST, other implementations may=20 >> be less direct. > >From what Nico said in earlier messages about the Programming Model for Mi= crosoft's TLS implementation (schannel SSP), the code above SSPI must know = an implement a lot of TLS message flow. > >According to that sketch, performing a TLS handshake requires a significan= t amount of code above SSPI, and performing a TLS renegotiation requires an= awful huge amount of code above SSPI. I have never used schannel myself (= and haven't found >programming examples yet), but it seems that the app on = top of SSPI _must_ know whether incoming data is application data, protecte= d application data or handshake messages and pass each of them to distinct = SSPI calls or get an error. >The return calls of those SSPI functions probably indicate which call to d= o next (or which kind of data to expect next). It is the return codes from the different APIs that tell you whether you sh= ould go back go negotiation or not. The application itself should never loo= k at the actual packets and make decisions on their own. >So an app on top of SSPI using the schannel SSP might not expect the clien= t to request rekeying at arbitrary times during communication and that unex= pected (protected) ClientHello handshake message is then passed to a Messag= e-unprotection call of >SSPI where it is rejected. >When that happens, the server seems to terminate the session (delete the s= ecurity context) and close the socket/connection, which might be the reason= why you receive a TCP RST. > > >Nico also mentioned, that with SSPI, the renegotiation context uses a diff= erent/seperate context handle that the original context. That is not entirely true. If a client wants to renegotiate, they just call= the proper API with the current context, which emits renegotiation and han= dshaking begins. >Which seems to imply, that for a TLS renegotiation by the app on top of SS= PI, the app has to call the message protection/unprotection calls of the pr= evious context for the initial handshake messages of the new context -- unt= il the Interator Function(s) >indicate that this is no longer necessary (be= cause ChangeCipherSpec has been sent). The way it works is that message protection/unprotection returns a special = error code instructing the application to start handshaking again, using th= e same context. >If TLS renegotiation actually works like this in SSPI, then an SSPI app is= actually playing the MITM-Attack every time that it renegotiates (i.e. it = would perform the MITM-Attack on its own TLS stack). It doesn't work this way, so you don't have to play the MiTM game itself. A= ll the details are hidden behind the SSPI APIs and one has to just react ba= sed on return values. Nasko From ekr@networkresonance.com Sat Nov 14 08:41:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73EE3A6A02 for ; Sat, 14 Nov 2009 08:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87TVb6wlcF5L for ; Sat, 14 Nov 2009 08:41:10 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id D52C93A688C for ; Sat, 14 Nov 2009 08:41:09 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9Lgy-0006VT-00 for tls@ietf.org; Sat, 14 Nov 2009 18:41:40 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 70D5D69F6AA; Sat, 14 Nov 2009 18:42:44 +0200 (EET) Date: Sat, 14 Nov 2009 18:42:44 +0200 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20091114091405.GK1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <20091113230816.753DB69F515@kilo.networkresonance.com> <20091114082813.GD1105@Sun.COM> <20091114090519.8154569F5C3@kilo.networkresonance.com> <20091114091405.GK1105@Sun.COM> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091114164244.70D5D69F6AA@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 16:41:10 -0000 At Sat, 14 Nov 2009 03:14:05 -0600, Nicolas Williams wrote: > > On Sat, Nov 14, 2009 at 11:05:18AM +0200, Eric Rescorla wrote: > > At Sat, 14 Nov 2009 02:28:13 -0600, > > Nicolas Williams wrote: > > > > > > On Sat, Nov 14, 2009 at 01:08:16AM +0200, Eric Rescorla wrote: > > > > At Fri, 13 Nov 2009 10:46:09 -0600, > > > > Nicolas Williams wrote: > > > > > The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject > > > > > "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 > > > > > yesterday most certainly described no Hello extensions, only a Finished > > > > > message verify_data computation change. > > > > > > > > Yes, and it doesn't allow you to probe in a compatible way. > > > > > > No, that's not correct. On initial connection there's no need to do > > > anything special (sure, it's nice to know that your peer doesn't have > > > this vuln, but you don't have to). > > > > Well, I don't know what "have to" means. Some clients may have > > the policy of not connecting to servers that aren't upgraded. > > The existing proposal allows that. Yours does not. > > Indeed, though I'm not too concerned by that. For me that is a > trade-off to make w.r.t. complications raised by using extensions in the > first place (bear with me, please). > > IIUC the arguments about SSLv3, there's an installed base of SSLv3 and > TLS 1.0-with-bugs that is more likely to get patched to fix this and > only this than to get upgraded t TLS 1.1+ or to have all their bugs > patched. I'm not sure that that's true. IF it is true, then we have to > consider the possibility of designing the fix so that it's easier to > patch those. As I said, clients offer extensions already and know how to fall back to not using extensions. I don't see that there is a problem here. -Ekr From nelson@bolyard.me Sat Nov 14 10:23:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889DE3A67B0 for ; Sat, 14 Nov 2009 10:23:25 -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 qgg8urUaKzIJ for ; Sat, 14 Nov 2009 10:23:22 -0800 (PST) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id 990F03A67A5 for ; Sat, 14 Nov 2009 10:23:22 -0800 (PST) Received: (qmail 1099 invoked from network); 14 Nov 2009 18:23:51 -0000 Received: from unknown (24.5.142.42) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 14 Nov 2009 18:23:51 -0000 Message-ID: <4AFEF62B.5030303@bolyard.me> Date: Sat, 14 Nov 2009 10:25:47 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <4AFE4091.10005@jacaranda.org> In-Reply-To: <4AFE4091.10005@jacaranda.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 18:23:25 -0000 On 2009-11-13 21:30 PDT, David-Sarah Hopwood wrote: > [*] There is a corner case in which this argument might not apply -- > the "Step-Up" protocol, where old versions of the Netscape browser > would initially offer only 40-bit ciphersuites, and then renegotiate > to use a stronger ciphersuite if they see that a bit is set in the > certificate. Such browsers are obviously unpatched, and will fail to > renegotiate with a patched server that is using a Step-Up certificate. > > Note that "Step-Up" is different from "Server-Gated Cryptography" > (SGC), in which the client never completes the first handshake and > reconnects in a new session: SGC does not rely on renegotiation. > (Verisign/Thawte sells certs that support both and does not > distinguish between them; don't be confused by that.) > > Step-Up was a Netscape proposal, and SGC was from Microsoft. > I don't think that Internet Explorer ever implemented Step-Up (as > opposed to SGC). I believe that's correct, and likewise, Netscape never implemented SGC. > Netscape only implemented it in versions 3.x and 4.x, which have numerous > arbitrary code execution bugs that would be easier to exploit. I would add that Mozilla browsers use TLS code inherited from Netscape. All the Netscape and Mozilla export browsers implemented Step-Up until the U.S. export regulations changed in the year 2000. > So this is not a significant issue at all -- any sites that are still > using Step-Up certs, would be well advised to just patch their servers > and tell their users to stop using such old browser versions. I agree, emphatically. But I have been told that there are still CA selling step-up certs to this day, because there are still server admins buying them, because there are still users in the world using those old clients. Given the premium prices historically obtained for Step-Up certs, I'm not optimistic that CAs will voluntarily cut off sales of their highest margin products for the good of a few users whose systems are hopelessly vulnerable anyway. /Nelson Bolyard Developer of TLS code used in Mozilla and (formerly) Netscape clients From nelson@bolyard.me Sat Nov 14 11:10:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8463A67ED for ; Sat, 14 Nov 2009 11:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 tuQBTJGWRMzJ for ; Sat, 14 Nov 2009 11:10:49 -0800 (PST) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by core3.amsl.com (Postfix) with SMTP id 1E9B83A67B0 for ; Sat, 14 Nov 2009 11:10:48 -0800 (PST) Received: (qmail 4948 invoked from network); 14 Nov 2009 19:11:19 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 14 Nov 2009 19:11:19 -0000 Message-ID: <4AFF0153.3090005@bolyard.me> Date: Sat, 14 Nov 2009 11:13:23 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> In-Reply-To: <20091113164608.GT1105@Sun.COM> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 19:10:50 -0000 On 2009-11-13 08:46 PDT, Nicolas Williams wrote: > On Fri, Nov 13, 2009 at 10:22:35AM +0200, Eric Rescorla wrote: >> At Thu, 12 Nov 2009 14:38:47 -0600, > Nicolas Williams wrote: >>> Interestingly, that approach could even be used on initial >>> connections to detect if the server will support secure >>> re-negotiation _before_ the client ever tries it. >> >> I don't see that. AFAICT both your options involve the client >> generating a hello extension, so this does affect the bits on the wire. >> Obviously there are approaches which don't require that, but they don't >> provide detection of server capabilities on initial negotiation. By >> contrast your message of 1854 doesn't allow the client to probe the >> server AFAICT. > > The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject > "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 > yesterday most certainly described no Hello extensions, only a Finished > message verify_data computation change. EKR and Marsh Ray and some others will recall that I proposed essentially the same proposal that Nico is now proposing in the meeting meeting in Mountain View on September 29, 2009 to which Marsh Ray invited EKR, myself and numerous others from this working group. I proposed that a change in the computation of the TLS Finished message to include some value derived from the master secret previously in use on the connection before the current renegotiation (such as the Finished message contents or some other value "extracted" from the master secret) would avoid the overhead of the new extensions on the wire. My goal was to avoid the extra bandwidth and memory cost of those extensions, which might be deemed too costly in certain low memory or bandwidth constrained applications. Others in the meeting responded that changing the definition of the computation of the Finished messages was a change to the base protocol specification (which adding an extension is not), and thus the change I proposed would make TLS become (say) TLS 1.3. The proposed new extension could be implemented as a patch to an extant implementation of TLS 1.0, but an implementation of TLS 1.3 would presumably require the implementation of all the changes in TLS 1.1 and 1.2 first, which would be a much bigger and slower undertaking for many TLS implementations. So, for the sake of hasty implementation, we abandoned the approach that redefines the Finished message and went with the new extension. But perhaps we should regard the new extension as a short term expedient, and plan to change the definition of the Finished message in TLS 1.3, so that the extension will no longer be necessary at some point in the future (when TLS 1.3 has become common place, maybe 10 years hence). Does the Working Group share interest in redefining the Finished message computation for TLS 1.3? From Nicolas.Williams@sun.com Sat Nov 14 14:00:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB8A3A679C for ; Sat, 14 Nov 2009 14:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 orcQo7wxXTf1 for ; Sat, 14 Nov 2009 13:59:59 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 2E4443A6359 for ; Sat, 14 Nov 2009 13:59:59 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAEM0TKP013229 for ; Sat, 14 Nov 2009 22:00:29 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 nAELqxvU017263 for ; Sat, 14 Nov 2009 14:53:00 -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 nAELXstB020529; Sat, 14 Nov 2009 15:33:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAELXr8p020528; Sat, 14 Nov 2009 15:33:53 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 14 Nov 2009 15:33:53 -0600 From: Nicolas Williams To: Nelson B Bolyard Message-ID: <20091114213353.GN1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <4AFF0153.3090005@bolyard.me> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFF0153.3090005@bolyard.me> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 22:00:00 -0000 On Sat, Nov 14, 2009 at 11:13:23AM -0800, Nelson B Bolyard wrote: > On 2009-11-13 08:46 PDT, Nicolas Williams wrote: > > The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject > > "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 > > yesterday most certainly described no Hello extensions, only a Finished > > message verify_data computation change. > > EKR and Marsh Ray and some others will recall that I proposed essentially > the same proposal that Nico is now proposing in the meeting meeting in > Mountain View on September 29, 2009 to which Marsh Ray invited EKR, myself > and numerous others from this working group. > > I proposed that a change in the computation of the TLS Finished message > to include some value derived from the master secret previously in use on > the connection before the current renegotiation (such as the Finished > message contents or some other value "extracted" from the master secret) > would avoid the overhead of the new extensions on the wire. My goal was > to avoid the extra bandwidth and memory cost of those extensions, which > might be deemed too costly in certain low memory or bandwidth constrained > applications. > > Others in the meeting responded that changing the definition of the > computation of the Finished messages was a change to the base protocol > specification (which adding an extension is not), and thus the change > I proposed would make TLS become (say) TLS 1.3. All things considered, I bet that the finished message verify_data computation change is the simplest one to make. Saying that because it falls outside the spectrum of extensions that can be considered in TLS 1.0-1.2 it can't be considered is a bit of a stretch. Imagine if we had no client hello extensions, or that we couldn't use them because in practice support for them was very spotty, then we'd have to resort to this approach and no one would say "but we can't unless we call it TLS 1.3"! That said, I don't think we need to change EKR's proposed fix. My purpose in throwing it out, with the big caveat that I included, was to get those who are worried about SSLv3 to provide specific rationales for why an extension-less approach should be preferable. I.e., I was trying to condense the SSLv3 sub-threads. > But perhaps we should regard the new extension as a short term expedient, > and plan to change the definition of the Finished message in TLS 1.3, > so that the extension will no longer be necessary at some point in the > future (when TLS 1.3 has become common place, maybe 10 years hence). There's a certain, er, desire for something like a "secure bit" that can be used to passively detect broken implementations. With EKR's fix we get that bit. I don't really care for that bit: servers should be patched, period, rejecting re-negotiations from unpatched clients, and clients should be patched and should refuse to complete re-negotiation with unpatched servers and complain _loudly_ about them -- that is the least that we need, and IMO also all we need. > Does the Working Group share interest in redefining the Finished message > computation for TLS 1.3? I doubt it. Once the use of hello extensions is demonstrated to work even for critical cases and when server hello extensions are needed, then there's no need to change to using an unsignalled fix as in your/my proposals. However, I personally very much like the idea of a generic channel binding facility in TLS, not so much for the purpose of channel binding TLS to other channels (since EKR's fix takes care of the one case where we need that) but for providing support to StartTLS-style applications for authenticating pre-StartTLS negotiations. For that, your/my proposals will do (only using application-provided data as the "channel bindings"). Nico -- From djhopwood@googlemail.com Sat Nov 14 14:01:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADCB73A679C for ; Sat, 14 Nov 2009 14:01:53 -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 ogs5kNOjI6LT for ; Sat, 14 Nov 2009 14:01:52 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 4DE4F3A6359 for ; Sat, 14 Nov 2009 14:01:52 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1426201eyd.51 for ; Sat, 14 Nov 2009 14:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=U1ytpuN8eIaIOzlF7uEEHQj43u3jCNELRNAUO842mHs=; b=SS5YPdVWFLM2hUXyctGw1AB9JeN0dm5cFN9/Ngh5+DtVdVJpymemMrZi60QZJ5+PFD FTCc7tgmulnvvYaW/qW6nigcpJXRc0mTfWjJjBJxic2dqLwWwROwBnaqnBqEqJBFUIgh FXVj+UZW0q47IG9yRlnnuuaOAkMGKwTITUYi0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Bbfk8mB72EZbgqQwKCzCVBKQQgA65UO8UYiTFn4DJB+7DM5itieVxhEN0wb7RTXtAY aKtJuBsT3Ehk47caU4MO/0HLumwKSxkLm9Ix2tQBxZJb9AVsEtaPEofMYnO5G1u+F33T QvMG2mjTuPFEQ2WAMskTTPyZTG2OVGJ6H0p9I= Received: by 10.213.24.9 with SMTP id t9mr2475329ebb.4.1258236135834; Sat, 14 Nov 2009 14:02:15 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 7sm2827621eyg.17.2009.11.14.14.02.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 14:02:15 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFF28DE.4080709@jacaranda.org> Date: Sat, 14 Nov 2009 22:02:06 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <4AFE4091.10005@jacaranda.org> <20091114084115.GF1105@Sun.COM> In-Reply-To: <20091114084115.GF1105@Sun.COM> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1F70FD484894F8621322C2E8" Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 22:01:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1F70FD484894F8621322C2E8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > On Sat, Nov 14, 2009 at 05:30:57AM +0000, David-Sarah Hopwood wrote: >> David-Sarah Hopwood wrote: >>> The problem is that this unnecessarily breaks cases in which the >>> possibility of attack couldn't have been prevented (because only >>> one of the client and server supports the extension), and in which >>> there may actually be no attack. >> >> No, on further consideration this argument is wrong. Since adding the >> verify_data into the Finished hashes would only happen for renegotiati= ons, >> it cannot cause any interoperability failures on an initial handshake.= >> It would cause a handshake failure on a renegotiation, if only the cli= ent >> or only the server has been patched. >=20 > Right. >=20 >> Note that a handshake failure in that case doesn't necessarily result = in >> an interoperability failure. [...] >=20 > Right. >=20 >> On the other hand, consider the case of a patched client performing an= >> initial handshake with an unpatched server. If an extension is not use= d, >> then there is no way for the client to tell that the server is unpatch= ed, >> and the connection might succeed even though an attack is taking place= =2E >> Using the extension would give patched clients the option of refusing = to >> connect to unpatched servers. >=20 > Irrelevant: nothing that goes over the first connection should be at > risk or sensitive, provided that the client did authenticate the server= > OR, if an anon-anon cipher suite was used, (that the client refrained > from sending confidential data AND the client did not take destructive > action based on data from the server). No, that's not correct. The client's session may have been prefixed by data chosen by the attacker. Therefore everything sent in that session is= at risk. This depends to some extent on the application protocol, but I would expect almost all protocols to be potentially vulnerable -- although not all implementations. > It's OK for the client to learn that the server is unpatched when it > tries to re-negotiate. An attack can occur even against connections of a client that *never* renegotiates, if it is connecting to an unpatched server. >> The converse situation, where a patched server does not know whether i= t >> is talking to a patched or unpatched client, is probably less signific= ant: >> an attack can only succeed in that case if the client does not check t= he >> server's certificate, in which case a MITM attack is possible anyway. >=20 > Right. >=20 >> Important point: TLS- or extension-intolerant servers are all unpatche= d. >=20 > Yes. But I get the feeling that some folks think it will be easier to > patch them than to upgrade them. My proposal is particularly useful > then, since it can be applied even to SSLv3. The easiest patch is to just disable renegotiation. If you're going to do anything more complicated than that, I don't think it makes any sense at all to leave the server in a state where it is still TLS- or extension-intolerant. Note that we don't need such servers to support TLS; only to tolerate a TLS ClientHello with extensions, and perform version negotiation correctl= y for whatever version(s) they do support. > NOTE: I'm not trying to force a design change at this late stage. I ha= d > a caveat at the top of my proposal that it should only be > considered if the use of extensions turned out to be problematic.= Yes, that also applies to my suggestion of adding in the Finished hashes unconditionally for renegotiations, and treating the extension as advisory. It would be helpful to know to what extent implementors of commonly used clients actually still think that it is problematic to use extensions on an initial handshake. (For HTTPS, it would be particularly interesting to know what Internet Explorer's behaviour would be once it i= s patched.) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig1F70FD484894F8621322C2E8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr/KOYACgkQWUc8YzyzqAd3cgD+NFM9W9TVQPeKUrITWt0PPHJv L7Z8lTjlGHa6iT5BrmMA/iBz2wZukd3IHITAJ+x9j9MKgMJ3Gi3It3fQrQ5uW2nn =GYjg -----END PGP SIGNATURE----- --------------enig1F70FD484894F8621322C2E8-- From djhopwood@googlemail.com Sat Nov 14 14:08:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305353A6359 for ; Sat, 14 Nov 2009 14:08:39 -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 qyHtpNjAOmRY for ; Sat, 14 Nov 2009 14:08:38 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id B29443A679C for ; Sat, 14 Nov 2009 14:08:37 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1427891eyd.51 for ; Sat, 14 Nov 2009 14:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=6+st7AeY7Z6/7/tQqIVcDq4f2wbr6saMw5dOg2tSJN0=; b=XjJLR36Y1OnoW3z1M/yhtC7EF9R8kGruVEhJb/p5hfFweA5rkomAso2st2Oxf/1wr2 QULBei7+WbdHjP4r3JfCT3oLJjBjIGAG5DOZpbhUwk2q9rYHEC1UnuW4vq60izdEi+vh FqWYt6BRp2nzkdoRYCrtfApVi326fXTMKBgNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=oKMLlQ+NUnm/8fkW03rj+no/Nfkjv7HRO68f6l1V3Zo2tMzuJSe/ZTLCT6OUldWFsD z7wqSVPpS4P9XWZ72S6GMBaJsRXyrlnlQtKFlevQEpkAec3++QxCxl4tRbYS9uSK11os xE9ykrdVRT8XrfpV4l8N3wGD71NlIEN1UZvWA= Received: by 10.213.23.155 with SMTP id r27mr3927208ebb.25.1258236545880; Sat, 14 Nov 2009 14:09:05 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 5sm2804972eyh.18.2009.11.14.14.09.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 14:09:05 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFF2A80.2010908@jacaranda.org> Date: Sat, 14 Nov 2009 22:09:04 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <4AFE4091.10005@jacaranda.org> <4AFE5673.9080101@jacaranda.org> <20091114084358.GG1105@Sun.COM> In-Reply-To: <20091114084358.GG1105@Sun.COM> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig12B39FE0BF2FE90A6AEEA721" Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 22:08:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig12B39FE0BF2FE90A6AEEA721 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > On Sat, Nov 14, 2009 at 07:04:19AM +0000, David-Sarah Hopwood wrote: >> Still, that's no worse than the situation with the current >> draft-rescorla-tls-renegotiate. So I think that what I suggested: >> >>> [...] only use an extension >>> as an advisory of patched status (i.e. say that an empty extension SH= OULD >>> be sent if patched), but add the verify_data into the Finished hashes= >>> unconditionally (i.e. as a MUST) for renegotiating handshakes. Then, = the >>> concerns about extensions potentially breaking some servers, and the >>> concerns about lack of an extension potentially resulting in a securi= ty >>> weakness (due to a client being unable to tell whether a server is pa= tched), >>> would only arise in mutually exclusive sets of cases. >> is still an overall improvement. >=20 > I think that adding to my proposed fix an _optional_ signal in the > client's hello (and, correspondingly, in the server hello), would be > just fine. I don't believe it's necessary. So we differ on whether sending signals in the hello messages is a "MAY" or a "SHOULD". Here are the key-word definitions from RFC 2119: # 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the # definition is an absolute requirement of the specification. # 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there # may exist valid reasons in particular circumstances to ignore a # particular item, but the full implications must be understood and # carefully weighed before choosing a different course. # 5. MAY This word, or the adjective "OPTIONAL", mean that an item is # truly optional. One vendor may choose to include the item because a= # particular marketplace requires it or because the vendor feels that # it enhances the product while another vendor may omit the same item.= # An implementation which does not include a particular option MUST be= # prepared to interoperate with another implementation which does # include the option, though perhaps with reduced functionality. In th= e # same vein an implementation which does include a particular option # MUST be prepared to interoperate with another implementation which # does not include the option (except, of course, for the feature the # option provides.) Since this can affect security and not just functionality, I think that SHOULD is clearly appropriate here (but MUST is not). --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig12B39FE0BF2FE90A6AEEA721 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr/KoEACgkQWUc8YzyzqAccpAD/RWn2MyIGcn7ljQea1NQLCiBx OjbCKUdv4gOCert89WoA/j9rAe5RXLuVn/0X6YH/nGsSDpMWF5hd06w5QeGRWEpd =TUGL -----END PGP SIGNATURE----- --------------enig12B39FE0BF2FE90A6AEEA721-- From nelson@bolyard.me Sat Nov 14 14:46:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EAF3A682D for ; Sat, 14 Nov 2009 14:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 8DAnrN5PWlxy for ; Sat, 14 Nov 2009 14:46:16 -0800 (PST) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id 6B3783A6806 for ; Sat, 14 Nov 2009 14:46:16 -0800 (PST) Received: (qmail 21364 invoked from network); 14 Nov 2009 22:46:47 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 14 Nov 2009 22:46:47 -0000 Message-ID: <4AFF33D2.4050705@bolyard.me> Date: Sat, 14 Nov 2009 14:48:50 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <4AFF0153.3090005@bolyard.me> <20091114213353.GN1105@Sun.COM> In-Reply-To: <20091114213353.GN1105@Sun.COM> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 22:46:17 -0000 On 2009-11-14 13:33 PDT, Nicolas Williams wrote: > On Sat, Nov 14, 2009 at 11:13:23AM -0800, Nelson B Bolyard wrote: >> Does the Working Group share interest in redefining the Finished message >> computation for TLS 1.3? > > I doubt it. Once the use of hello extensions is demonstrated to work > even for critical cases and when server hello extensions are needed, > then there's no need to change to using an unsignalled fix as in your/my > proposals. Well, I'd consider use of the version number 0x0304 (for SSL 3.4, which is TLS 1.3) in the client hello to be an effective signal. I hope there will be more responses, so that we can get a sense of consensus for or against this idea. From djhopwood@googlemail.com Sat Nov 14 15:40:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EEC13A680B for ; Sat, 14 Nov 2009 15:40:21 -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 nd7YjXU0G76V for ; Sat, 14 Nov 2009 15:40:20 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 3A46F3A6783 for ; Sat, 14 Nov 2009 15:40:20 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so639066fga.13 for ; Sat, 14 Nov 2009 15:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=dEFfri7omzlWiAE8T02dA7h4AQBOyjBRfD9QLQ6SHvo=; b=NGYZOsPTrFaXGVGmxwyAJWymakbSswz7aN5uhPQra1CmdXCkbb6gk/7FBpyGpdiuhL xbuO/X8Gz1XmzhmoCuEyI0ye28oKInpeM1edF/Dtp9yhRcaGJ7fAPYgsvOy/QTC0t4k4 Eo5s+DqK415aKyoLOl0o5QGa7nd0qmUNf3piA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=rrxhQ1ksvVxL/PZjb3o6rlmzJtLFwYgDz6ZsqomLc/1cZS9dMIr9tCoaTwD1sYOaIC FOej6n1FeBj4ViWz0Jx0YsKMoMIlH3lwDvtAeiR/gI7oODeRg0WOQnANf61KPWXmpCnU d2Gf6SRwt/m+tIKU2skhEw1vHU4Bo2el0H1qA= Received: by 10.216.86.131 with SMTP id w3mr59900wee.156.1258242048034; Sat, 14 Nov 2009 15:40:48 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 28sm1895642eye.9.2009.11.14.15.40.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 15:40:47 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFF3FFE.1060607@jacaranda.org> Date: Sat, 14 Nov 2009 23:40:46 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <4AFF0153.3090005@bolyard.me> <20091114213353.GN1105@Sun.COM> <4AFF33D2.4050705@bolyard.me> In-Reply-To: <4AFF33D2.4050705@bolyard.me> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigECB3FBB5821D7756A6DFE91D" Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 23:40:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECB3FBB5821D7756A6DFE91D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nelson B Bolyard wrote: > On 2009-11-14 13:33 PDT, Nicolas Williams wrote: >> On Sat, Nov 14, 2009 at 11:13:23AM -0800, Nelson B Bolyard wrote: >=20 >>> Does the Working Group share interest in redefining the Finished mess= age >>> computation for TLS 1.3? >> >> I doubt it. Once the use of hello extensions is demonstrated to work >> even for critical cases and when server hello extensions are needed, >> then there's no need to change to using an unsignalled fix as in your/= my >> proposals. >=20 > Well, I'd consider use of the version number 0x0304 (for SSL 3.4, which= > is TLS 1.3) in the client hello to be an effective signal. If you mean that TLS 1.3 would add the verify_data to renegotiating handshakes implicitly, but previous versions would rely on the extension:= I think that would just create additional code paths, greater complexity,= and more opportunities for implementors to screw up in ways that introduc= e forward compatibility problems. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigECB3FBB5821D7756A6DFE91D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr/P/8ACgkQWUc8YzyzqAfrrQD/dSZFDfBMpz6h30K1cDRapD04 E75f0vBH9h70sKT/B9QA/RM2XvW7gs5FnSTXoLhBxVY2voJ6gYHFemRkXa97Tcz2 =GvRm -----END PGP SIGNATURE----- --------------enigECB3FBB5821D7756A6DFE91D-- From mrex@sap.com Sat Nov 14 16:14:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F42E3A6768 for ; Sat, 14 Nov 2009 16:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.073, 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 sH9m6goaYEGx for ; Sat, 14 Nov 2009 16:14:44 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 9E7043A672E for ; Sat, 14 Nov 2009 16:14:43 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAF0FDho012598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 01:15:13 +0100 (MET) From: Martin Rex Message-Id: <200911150015.nAF0FCoj012443@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Sun, 15 Nov 2009 01:15:12 +0100 (MET) In-Reply-To: <20091114164244.70D5D69F6AA@kilo.networkresonance.com> from "Eric Rescorla" at Nov 14, 9 06:42:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 00:14:44 -0000 Eric Rescorla wrote: > > > > IIUC the arguments about SSLv3, there's an installed base of SSLv3 and > > TLS 1.0-with-bugs that is more likely to get patched to fix this and > > only this than to get upgraded t TLS 1.1+ or to have all their bugs > > patched. I'm not sure that that's true. IF it is true, then we have to > > consider the possibility of designing the fix so that it's easier to > > patch those. > > As I said, clients offer extensions already and know how to fall > back to not using extensions. I don't see that there is a problem > here. I think you're mistaken. The common Web Browsers may have such a fallback, but there are much more users of TLS than just Web Browsers. The majority of programmatic clients don't use such a fallback. Remember, that this fallback is entirely an apps thingy -- you can not put it into TLS itself. So you will need to patch every app using TLS to add a reconnect fallback in order to be able to use TLS extension RI and not loose connectivity. The reconnect fallback is a performance problem by itself, and requires a significant of code added to the app. I'm sorry, but I don't like this idea at all. If the problem was so severe that all Browsers added the reconnect fallback, that it is possibly to big to ignore it now. -Martin From mrex@sap.com Sat Nov 14 17:45:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAA93A68ED for ; Sat, 14 Nov 2009 17:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 YPCHCqX7EnWc for ; Sat, 14 Nov 2009 17:45:07 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id AC5EA3A685A for ; Sat, 14 Nov 2009 17:45:06 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAF1jaJg020447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 02:45:36 +0100 (MET) From: Martin Rex Message-Id: <200911150145.nAF1jZEf017404@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Sun, 15 Nov 2009 02:45:35 +0100 (MET) In-Reply-To: <20091114074136.3BFB969F59C@kilo.networkresonance.com> from "Eric Rescorla" at Nov 14, 9 09:41:31 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Protected Renegotiation -- refined proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 01:45:08 -0000 Eric, Maybe you remember my privat Email to Steve and Marsh (you were cc) 3 hours after I had posted my observation about the MITM susceptibility of the TLS renegotiation: An approach to fixing the situation would be to use a TLS extension to securely identify the session that is to be renegotiated. Fixed clients would have to identify the TLS session that they want to renegotiate. Once the fixed clients are shipped, the fixed servers can require clients to identify the to-be-renegotiated session and abort if they don't. In the initial in-the-clear TLS-handshake, the clients should indicate with this extension (and and empty extension data) that the clients supports secure renegotiation, so that the server may defer the sending of a ClientCertificateRequest in the initial handshake to a later renegotiation. This matches the TLS extension RI that you published the next day. Cryptographically, the approach of the TLS extension RI looks fine, but I having thought about it for a few days, I really dislike how this fix is integrated into the protocol. The lack of protection of the renegotiation is a flaw of the SSL/TLS base protocol, and so it REALLY should be fixed there. If the original SSL protocol had used different finished calculations for initial and renegotiate handshakes, then we wouldn't have the problem that a clients initial handshake can be proxied into the renegotiation of the server. Now that we know that this was a stupid mistake, we should not continue with this mistake. The original TLS renegotiation is a security problem and should be entirely abandoned. Changing the finished message calculation for the TLS renegotiation by virtually adding the verify_data from the currents session finished messages to the handshake messages (hashes) of the renegotiation handshake is the most natural solution. There really is no point in wasting the network bandwith and send the verify_data over the network. What we should add to the protocol is the signaling of this protocol change Client->Server and Server->Client through the ClientHello and ServerHello handshake messages. The most interoperable signaling C->S is a specially assigned ciphersuites ID, we probably do not need to discuss that. I'm open to sugestions for the S->C signaling. Since the Server will signal only when he sees the clients signal in the ClientHello, you could at that point actually change the ServerHello message. Changing the ServerHello is NOT going to break anything here! IMNSHO the IETF should _NOT_ continue to support the insecure original TLS renegotiation, the implementors can decide themselves whether they want to or need to offer their customers that configuration option and use the original Finished message calculation if the negotiation (=signaling C->S and S->C) indicates that at least one of the peers has not been updated. TLS v1.3 should REALLY require that only the modified finished message calculation may be used for TLS renegotiation. Supporting the original TLS renegotiation in TLS v1.3 would be unreasonable, and if we use the TLS extension RI, then we would have to keep that band-aid forever wasting network bandwidth. And all those vendors and implementors who have added a reconnect-fallback to their TLS clients, - I do not want the IETF recommend them to trash this fallback - I do not want the IETF leave the fallback handshake unprotected If we do NOT use the TLS extension RI on the initial handshake, but instead a different signaling, then both of this is unnecessary, the vendors can have their TLS client still signal and use the protected renegotiation, encounter less connection drops and the ability to produce better error messages. I do admit that tunneling the Finished Messages through TLS extensions in ClientHello and ServerHello into the Handshake message hash might require ~20 lines of code less for TLS implementations that already implement the extensions code. Personally, I think the un-usability that comes with a strict requirement for TLS extensions and the uncertainty for the fallbacks, the impaired error reporting and the waste of network bandwidth saves the consumers of this technology MUCH MUCH more every day in the future. And every implementer that doesn't have TLS extensions all of the codebase that he maintains will have to add much more for tls extensions than for the actual fix. I guess, I will have to write an I-D so that we can let the community decide (this probably is no longer an TLS WG internal decision, because it affects the internet as a whole). -Martin From Nicolas.Williams@sun.com Sat Nov 14 18:12:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A882E3A67B8 for ; Sat, 14 Nov 2009 18:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 vft9gO-U96tb for ; Sat, 14 Nov 2009 18:12:36 -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 3DC363A6784 for ; Sat, 14 Nov 2009 18:12:35 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAF2D39Z026007 for ; Sun, 15 Nov 2009 02:13:03 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 nAF2D3GF033062 for ; Sat, 14 Nov 2009 19:13:03 -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 nAF1rvWS020711; Sat, 14 Nov 2009 19:53:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAF1rvcN020710; Sat, 14 Nov 2009 19:53:57 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 14 Nov 2009 19:53:57 -0600 From: Nicolas Williams To: Nelson B Bolyard Message-ID: <20091115015357.GP1105@Sun.COM> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <4AFF0153.3090005@bolyard.me> <20091114213353.GN1105@Sun.COM> <4AFF33D2.4050705@bolyard.me> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFF33D2.4050705@bolyard.me> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 02:12:37 -0000 On Sat, Nov 14, 2009 at 02:48:50PM -0800, Nelson B Bolyard wrote: > On 2009-11-14 13:33 PDT, Nicolas Williams wrote: > > On Sat, Nov 14, 2009 at 11:13:23AM -0800, Nelson B Bolyard wrote: > >> Does the Working Group share interest in redefining the Finished message > >> computation for TLS 1.3? > > > > I doubt it. Once the use of hello extensions is demonstrated to work > > even for critical cases and when server hello extensions are needed, > > then there's no need to change to using an unsignalled fix as in your/my > > proposals. > > Well, I'd consider use of the version number 0x0304 (for SSL 3.4, which > is TLS 1.3) in the client hello to be an effective signal. Well, yes, but that wasn't your proposal on Sept 29, and it wasn't mine this past week. > I hope there will be more responses, so that we can get a sense of consensus > for or against this idea. I think the consensus is probably to go with EKR's fix as is. Note that my proposed fix could actually also be deployed for SSLv3 systems, IF it makes sense that they could get patched more easily than upgraded (which I doubt, but then, I've no data to go on). Once EKR's fix is deployed there will be no point to do a TLS 1.3 just to have an alternative fix -- why bother? Nico -- From mrex@sap.com Sat Nov 14 18:13:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133213A67F9 for ; Sat, 14 Nov 2009 18:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 xZLZZZ-wU-x6 for ; Sat, 14 Nov 2009 18:13:29 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BE59F3A67F1 for ; Sat, 14 Nov 2009 18:13:28 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAF2DwGQ022812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 03:13:58 +0100 (MET) From: Martin Rex Message-Id: <200911150213.nAF2DvaU019042@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Sun, 15 Nov 2009 03:13:57 +0100 (MET) In-Reply-To: <20091114164244.70D5D69F6AA@kilo.networkresonance.com> from "Eric Rescorla" at Nov 14, 9 06:42:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 02:13:30 -0000 Eric Rescorla wrote: > > > > IIUC the arguments about SSLv3, there's an installed base of SSLv3 and > > TLS 1.0-with-bugs that is more likely to get patched to fix this and > > only this than to get upgraded t TLS 1.1+ or to have all their bugs > > patched. I'm not sure that that's true. IF it is true, then we have to > > consider the possibility of designing the fix so that it's easier to > > patch those. > > As I said, clients offer extensions already and know how to fall > back to not using extensions. I don't see that there is a problem > here. There are still millions of Web Browsers in use out there that do not contain a fallback reconnect at the application level. MSIE 6 comes to mind (I use it on 4 different machines). A fix that only changes a small amount of code in schannel.dll is probably easy. But you're suggesting that MSIE6 needs to be enhanced with a fallback reconnect in order to allow the TLS renego patch to be applied without impairing connectivity/interoperability of MSIE6 with a part of the installed base. That sounds like poor engineering to me. We can fix this entirely in TLS in a highly interoperable fashion by using and existing protocol element in the ClientHello handshake message rather than a relatively new optional feature like TLS extensions that has demonstrated to cause significant interop problems. Personally I would not mind if in 6 months my Browser would start to warn me if I'm connecting to an unpatched server. But in order to do that, we MUST have a negotiation which will determine this reliably through ServerHello. Making assumptions why a connection was simply closed by the server (silently or with a fatal alert) will NOT provide this information. The TLS extension RI is unable to provide this information, and that is a significant shortcoming. -Martin -Martin From djhopwood@googlemail.com Sat Nov 14 18:17:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D59C3A67F1 for ; Sat, 14 Nov 2009 18:17:02 -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 2uSvlSI2cHkw for ; Sat, 14 Nov 2009 18:17:01 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 4D05C3A689C for ; Sat, 14 Nov 2009 18:17:00 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1484371eyd.51 for ; Sat, 14 Nov 2009 18:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=f9jqJx7GtLupF7qM4rjW1saC2mLgQZIjR0+cC9xEkuM=; b=eM0bsajR8kenM1ydlrw1iFC7ekbeZJTUGZ0C4ByNfyNa3JItFluqSNJFZa9SD+8UTu 8hq6PT0jYAjhnOGhxuN3TKM7rCevpFEZACWfhednLw3qovcWmt7mr1DRS21sAdhuFX8B 0tjUO6sVurV25Z3Z89mPOWMK2KtM5JIkplFzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Qsfto1urKpfWIgtxV8ZitoMHf4+zl57mRrLNCF/KJQGq+q4q7sI2IxV4kc0/Rj9jTJ ZfdvHdQKduvCkMrZao4OB9tUiUEBoOzMoA00MsyOm6A0oyhAX3S06D6YB/C3saKa6nwd jYwSqtQ8PgC0VPQL0cmWYBeyTDzGJ3oew2TpU= Received: by 10.213.96.6 with SMTP id f6mr3922790ebn.31.1258251448139; Sat, 14 Nov 2009 18:17:28 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 10sm3947935eyz.3.2009.11.14.18.17.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 18:17:23 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFF64A9.30108@jacaranda.org> Date: Sun, 15 Nov 2009 02:17:13 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911150015.nAF0FCoj012443@fs4113.wdf.sap.corp> In-Reply-To: <200911150015.nAF0FCoj012443@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3C9D737399A43DB43AD1C534" Subject: Re: [TLS] History of extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 02:17:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C9D737399A43DB43AD1C534 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Eric Rescorla wrote: >> Nicolas Williams wrote: >> >>> IIUC the arguments about SSLv3, there's an installed base of SSLv3 an= d >>> TLS 1.0-with-bugs that is more likely to get patched to fix this and >>> only this than to get upgraded to TLS 1.1+ or to have all their bugs >>> patched. I'm not sure that that's true. IF it is true, then we have= to >>> consider the possibility of designing the fix so that it's easier to >>> patch those. >> >> As I said, clients offer extensions already and know how to fall >> back to not using extensions. I don't see that there is a problem >> here. >=20 > I think you're mistaken. >=20 > The common Web Browsers may have such a fallback, but there are > much more users of TLS than just Web Browsers. Yes, of TLS. Not so much of SSL. Most specifications for carrying other protocols started with TLS, not SSLv3. There may still be some instances of extension-intolerant servers other than web servers, but I'm not aware of any evidence that there are enough to consider that a significant problem. > The majority of > programmatic clients don't use such a fallback. Remember, that > this fallback is entirely an apps thingy -- you can not put it > into TLS itself. So you will need to patch every app using > TLS to add a reconnect fallback in order to be able to use > TLS extension RI and not loose connectivity. No, not at all. The idea that server bugs need to be addressed by complicated workarounds in clients is primarily a "feature" of the web (or more precisely the cultural and technical biases of web client implementors). In most other contexts, a more appropriate response to a server being broken, is to fix the server. In any case, the extension draft can and should be specified in such a way that even if a client does not send the extension on an *initial* handshake, a connection to a patched server will not be vulnerable. (The server does not *know* that the vulnerability has been avoided, but in fact it has.) > The reconnect fallback is a performance problem by itself, > and requires a significant of code added to the app. >=20 > I'm sorry, but I don't like this idea at all. Which idea? I didn't read Eric's post as recommending that all TLS clients should implement the fallback, or saying that they need to. (For stateful protocols, reconnection wouldn't necessarily work, anyway.) His point was that since web clients already implement the fallback, they won't fail to interoperate. For non-web clients, TLS- or extension-intolerance have not been demonstrated to be a significant issue. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig3C9D737399A43DB43AD1C534 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr/ZLAACgkQWUc8YzyzqAdHQQEAmgS3SkB3bZ8kdsxqg1KwR3qY LotAVgnsu/IHkyFDJYIA/jvY1tPdHC/T3jxCCrCjRvsTyNrtl05xtRcIh1fa7S/1 =41YE -----END PGP SIGNATURE----- --------------enig3C9D737399A43DB43AD1C534-- From mrex@sap.com Sat Nov 14 18:30:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CA33A6784 for ; Sat, 14 Nov 2009 18:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 tQ9vkIe+gU4o for ; Sat, 14 Nov 2009 18:30:03 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A26AF3A6359 for ; Sat, 14 Nov 2009 18:30:02 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAF2UTt3023522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 03:30:29 +0100 (MET) From: Martin Rex Message-Id: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Sun, 15 Nov 2009 03:30:28 +0100 (MET) In-Reply-To: <4AFF0153.3090005@bolyard.me> from "Nelson B Bolyard" at Nov 14, 9 11:13:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 02:30:03 -0000 Nelson B Bolyard wrote: > > I proposed that a change in the computation of the TLS Finished message > to include some value derived from the master secret previously in use on > the connection before the current renegotiation (such as the Finished > message contents or some other value "extracted" from the master secret) > would avoid the overhead of the new extensions on the wire. My goal was > to avoid the extra bandwidth and memory cost of those extensions, which > might be deemed too costly in certain low memory or bandwidth constrained > applications. > > Others in the meeting responded that changing the definition of the > computation of the Finished messages was a change to the base protocol > specification (which adding an extension is not), and thus the change > I proposed would make TLS become (say) TLS 1.3. Well, we have a security flaw in the base spec, specifically in the computation of the Finished messages for the TLS renegotiation, because it fails to provide a cryptographic binding to the session that is replaced. The correct approach to fix a defect in the base protocol is, of course, to fix the base protocol. The defect is specific to the TLS renegotiation and is so severe, that the IETF ought to strongly discourage any future use of the defective protocol feature. The negotiation will provide sufficient information to vendors and implementors to decide on their own whether and when to still support the defective protocol feature. TLS extensions are fairly new, cause interop problems and are purely optional protocol features. TLS extensions are _not_ part of the base spec of SSLv3, TLSv1.0 and TLSv1.1. The fix for this defect in the TLS renegotiation should be as close to mandatory as it can be and for all implementations of SSL/TLS independent of their protocol levels (SSLv3,TLSv1.0,TLSv1.1,TLSv1.2). The more I think about it, the more I'm opposed to using TLS extensions to wrap this fix. It's just to urgent and serious to spend such an amount of time on a fancy wrapping. -Martin From mike-list@pobox.com Sat Nov 14 18:59:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4983A6863 for ; Sat, 14 Nov 2009 18:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 Vh2Ni7QFKOE8 for ; Sat, 14 Nov 2009 18:59:38 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 98AAF3A6808 for ; Sat, 14 Nov 2009 18:59:36 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 748BF7FB6D for ; Sat, 14 Nov 2009 22:00:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=DElIJmBfqF/f qbbw2rrRBorQQqw=; b=d1BtlTibWgHuA7i3006i8xYqfeWdwSSzpycUDVy4tNnd GYDw4lT3XziuOl93dKHJNiiA2s1J7iMnTiaTvZOwAqLKDPaqLVUA5OZH0HY5GeoV UZ2HKLObsLY7jDTuNACffDRVbBHY0FJi3rsCssPm+UehJ12vQ8e5QJZn+JzTf3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=I0avmd MzBCCfveJ3sHv0V0/J0PH1+Ik0TMbTAyq7l148mHPqZRepPZjUDpnDWK5TYWgDeh otO30WAnL0I1tggAMd0X6hUizY9cJC2F2FuXuCDxD/Y/HY0qclhAneZL82UzlAGf AxZ5Vgj259yrl1G5OCopZ6cFDP2veGHGbekiw= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 71B257FB6C for ; Sat, 14 Nov 2009 22:00:07 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id EAAE87FB69 for ; Sat, 14 Nov 2009 22:00:06 -0500 (EST) Message-ID: <4AFF6EFA.6080508@pobox.com> Date: Sat, 14 Nov 2009 19:01:14 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> In-Reply-To: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: FB02973A-D192-11DE-B600-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 02:59:39 -0000 > The more I think about it, the more I'm opposed to using > TLS extensions to wrap this fix. It's just to urgent and serious > to spend such an amount of time on a fancy wrapping. I'm OK with whatever the fix becomes, but just want to point out that changing the Finished message calculation for renegotiations does not protect a patched client when talking to an unpatched server. Mike From marsh@extendedsubset.com Sat Nov 14 19:07:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04403A68AF for ; Sat, 14 Nov 2009 19:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 4WHjImo7abn2 for ; Sat, 14 Nov 2009 19:07:03 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 4361E3A68AA for ; Sat, 14 Nov 2009 19:07:03 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9VSg-0001ch-8V for tls@ietf.org; Sun, 15 Nov 2009 03:07:34 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id EF9556678 for ; Sun, 15 Nov 2009 03:07:32 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+vLw4+q2X5OR6I6lIFnOLzaF7LaQBr1dE= Message-ID: <4AFF7071.9050102@extendedsubset.com> Date: Sat, 14 Nov 2009 21:07:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> In-Reply-To: <4AFF6EFA.6080508@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 03:07:04 -0000 Michael D'Errico wrote: > changing the Finished message calculation for renegotiations > does not protect a patched client when talking to an unpatched > server. A patched client in 'secure' mode will have to refuse to handshake with an unpatched server. - Marsh From mrex@sap.com Sat Nov 14 19:22:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF323A68AB for ; Sat, 14 Nov 2009 19:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 oMMc0yIdNQqq for ; Sat, 14 Nov 2009 19:22:03 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E9C0B3A68AE for ; Sat, 14 Nov 2009 19:22:02 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAF3MU9W008018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 04:22:30 +0100 (MET) From: Martin Rex Message-Id: <200911150322.nAF3MTLA023042@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Sun, 15 Nov 2009 04:22:29 +0100 (MET) In-Reply-To: <20091115015357.GP1105@Sun.COM> from "Nicolas Williams" at Nov 14, 9 07:53:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 03:22:04 -0000 Nicolas Williams wrote: > > I think the consensus is probably to go with EKR's fix as is. Note that > my proposed fix could actually also be deployed for SSLv3 systems, IF it > makes sense that they could get patched more easily than upgraded (which > I doubt, but then, I've no data to go on). There simply may not be an upgrade available. The OEM SSL implementation that we have been shipped to our customers for the last 8 years is SSLv3 only. The next library that we are going to ship, and which I am currently validating, contains TLSv1.0 (still no extensions). We ordered this "upgrade" 1.5 years ago in order to be able to use GOST ciphersuites for customers in Russia. The library will provide a plugin interface for the GOST TLS ciphersuite(s), that plugin must be from a local provider and certified by authorized agencies. Switching to a different provider for the SSL implementation is not an option for us. The API architecture and credentials management is "proprietary" / specific to this software. One of our advantages is, that we have 100% backwards compatibility for all the improvements during the last 8 years and for the future, i.e. all of our customers get and use the same library (single codebase) independent of the Release of our application that they're using. The shared library/DLL is therefore compiled and tested on >40 different Platform variants (2-3 OS Releases per vendor, 32- and 64-bit). (that is part of my work). I know pretty well how much effort it is to upgrade a codebase from SSLv3 only to SSLv3+TLSv1.0, because I've been doing review and validation of those changes, changes in our app to allow configuration of the new features, interop testing, etc. Besides SSLv3, that library contains PKI-stuff, X.509 cert handling, GSS-API (SPKM-like), PKCS#7, PK credentials and trust anchor management, the crypto stuff for WS-Security. Our app does have programmatic clients that use SSL to access third party web-servers. The app doesn't have an re-connect fallback (what for -- since we have been supporting only SSLv3 all the time). -Martin From djhopwood@googlemail.com Sat Nov 14 19:38:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468C33A6912 for ; Sat, 14 Nov 2009 19:38:09 -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 9LN1FDxjKNAV for ; Sat, 14 Nov 2009 19:38:08 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 2BCE23A690B for ; Sat, 14 Nov 2009 19:38:08 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1502067eyd.51 for ; Sat, 14 Nov 2009 19:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=5b56wk6hAzjwQ0zt9hoc/qqPwvwTxRsR3MWgY//uagk=; b=r1ppqCfaLcXP6ZGDviLSv3h8U+3ixVctDJ0IA0zcxVD8Qp2SFlun94niVRAzQjxWp2 U1MEqaqiYV+1sAIF7YngQiAW1JPoOLOnY/OWogDAp6cF5shnrPd7Nc/BMG3lVf9qrmSC 0TZLWJtGD3Nfdfg4Bn56Y84QEfoP7XTiJO1hM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=T3GgcDN5JcuEtaDyBqNawViedM45XnTYKGZZdwmE1lHxSbCpQluanbErhndyg9a8mX 58s5pvS1yAH0pRvhBJsKkOyws/x4UE9y0JozvSW4mEv+QHWGRwVftoca5JNLAz06sykk C+rXSA7BaWySmC+c+112m3Mw9LYi8+GEen4Rg= Received: by 10.213.23.146 with SMTP id r18mr3679003ebb.74.1258256316300; Sat, 14 Nov 2009 19:38:36 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 24sm3055918eyx.37.2009.11.14.19.38.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 19:38:35 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4AFF77B1.1000106@jacaranda.org> Date: Sun, 15 Nov 2009 03:38:25 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> In-Reply-To: <4AFF7071.9050102@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB6AF7680F2DF7DE694BDD837" Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 03:38:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB6AF7680F2DF7DE694BDD837 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > Michael D'Errico wrote: >> changing the Finished message calculation for renegotiations >> does not protect a patched client when talking to an unpatched >> server. >=20 > A patched client in 'secure' mode will have to refuse to handshake with= > an unpatched server. Yes, but Michael's point was that changing the Finished message calculation alone does not allow the client to know that it is communicating with an unpatched server. The client's handshake is initial, so it does not include the verify_data in the Finished hash calculations, and neither does the server. That's why a separate indication of patched status is needed if you want to support the policy of refusing to connect to an unpatched peer. OTOH, if you change the Finished message calculation then this signalling is *only* needed to support that policy. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB6AF7680F2DF7DE694BDD837 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkr/d7gACgkQWUc8YzyzqAe5ngD/QNWZjXL265+SV0HBfgPzj51K r9lNGvvrnCdXX1Nd1egA/0Po+pz1xQWLAi1fW6B9DH4lPRHq6gKcyzvNthEUITyb =01xW -----END PGP SIGNATURE----- --------------enigB6AF7680F2DF7DE694BDD837-- From marsh@extendedsubset.com Sat Nov 14 19:45:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4B23A67EF for ; Sat, 14 Nov 2009 19:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 lt4tGqjZeJEa for ; Sat, 14 Nov 2009 19:45:42 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 5B6E93A67B1 for ; Sat, 14 Nov 2009 19:45:42 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9W45-0009qB-Cq for tls@ietf.org; Sun, 15 Nov 2009 03:46:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A7DED6678 for ; Sun, 15 Nov 2009 03:46:12 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19D59Wd/XuS4arv6iDeL4ID3svaA0vk3XA= Message-ID: <4AFF7981.90804@extendedsubset.com> Date: Sat, 14 Nov 2009 21:46:09 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: tls@ietf.org References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> In-Reply-To: <4AFF77B1.1000106@jacaranda.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 03:45:43 -0000 David-Sarah Hopwood wrote: > > Yes, but Michael's point was that changing the Finished message > > That's why a separate indication of patched status is needed Hi All, It's clear we're going to have to take a fresh look at this thing. I've worked up some additional requirements that we've come to understand. To follow in its own email. When I get some time (probably tomorrow) I'll try to summarize the approached people have come up with to address the implementation challenges. - Marsh From marsh@extendedsubset.com Sat Nov 14 19:46:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4C83A6912 for ; Sat, 14 Nov 2009 19:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 AcR5ot3o6Vb1 for ; Sat, 14 Nov 2009 19:46:17 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id B18103A6907 for ; Sat, 14 Nov 2009 19:46:17 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9W4e-000E0E-Mx for tls@ietf.org; Sun, 15 Nov 2009 03:46:48 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C07E36678 for ; Sun, 15 Nov 2009 03:46:47 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Xv6CFjlxBx2qoRBQDJn4+dJRkYjBLRN8= Message-ID: <4AFF79A4.6020706@extendedsubset.com> Date: Sat, 14 Nov 2009 21:46:44 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 03:46:18 -0000 The current draft-rescorla-tls-renegotiation represents a good solution, at least from the theoretical perspective. However, when one begins to consider the practical difficulties it is encountering in actual deployment it becomes clear that it is not likely to be a good solution in practice. It is for this reason that we need to look at other proposals with the aim of providing the most compatible and easiest to implement fix on existing systems. This means: === R5. Not using an extension to implement the fix. Currently there are no examples of extensions used in a critical role between interoperable systems, even where there would be significant gain (financial and otherwise) from their use (e.g., SNI). An urgent security-critical bug fix is absolutely not the place for blazing new trails. It appears that somewhere between 20% and 40% of current SSL/TLS traffic is between systems that either preferred not to (or could not) use TLS 1.0 with extensions. === R6. The fix must work for SSLv3. One source measured 22% of current SSL/TLS traffic still over SSLv3, and other sources of data have tended to confirm that. This is far too large a group to ignore, or expect to "just upgrade". Even software that does support newer versions of the protocol will often fall back to SSLv3 at the first sign of trouble. Any fix which does not address SSLv3 can simply be bypassed by the attacker === R7. The fix must be easy to merge across existing code branches. One vendor has an installed base of hundreds of millions of systems with SSL/TLS stacks designed before TLS extensions were well-defined or relevant. They and other vendors also have many legacy code branches they will have to patch. The main goal of these requirements is to restore the functionality of TLS on as many systems as possible, as quickly as possible. Solutions need to take into account development and testing processes, particularly those at vendors with a large installed base and many product lines. === R8. The fix must facilitate testing. Solutions with the potential to simplify testing processes could represent the biggest win in terms of time. For example, fixes which rely on extensions could represent more work for a test group that is currently set up for product lines that don't use them. === R9. Must interoperate perfectly with unpatched systems. If the patch causes disruption in trial deployments, it will likely not get a second look. Most sites will just patch to disable renegotiation entirely. ------- Restating some previously accepted requirements/features: === R1. Restores the security guarantee of continuity-of-identity when both endpoints have been patched. May be able to provide some benefits when one of the endpoints has been patched. === R2. Supports secure and compatible modes. Secure mode - endpoint will not allow any potentially dangerous connections with unpatched remotes. Compatible mode - endpoint may be willing to take some risks with an unpatched remote. This requirement is to allow for a transition period for everyone to patch and ultimately migrate to secure mode. The actual timeline is for admins and vendors to work out individually. === R3. Free of IPR claims. Oh it happens. === R4. Must indicate presence of patch in plaintext. Intrusion detection, network auditing, and firewall tools will benefit from seeing that the fix is applied in the unencrypted part of the initial handshake. For most sites, this is perhaps the only advantage the patch has over disabling renegotiation. Without it, many minimally-inspecting firewalls will be configured to simply drop all renegotiations. === Discuss, suggest, etc. please. - Marsh From mrex@sap.com Sat Nov 14 19:49:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DD43A67F9 for ; Sat, 14 Nov 2009 19:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 pPncldZ5Ux-O for ; Sat, 14 Nov 2009 19:49:10 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E4B3A3A67E2 for ; Sat, 14 Nov 2009 19:49:09 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAF3ndgE025513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 04:49:40 +0100 (MET) From: Martin Rex Message-Id: <200911150349.nAF3ndet024229@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Sun, 15 Nov 2009 04:49:39 +0100 (MET) In-Reply-To: <4AFF6EFA.6080508@pobox.com> from "Michael D'Errico" at Nov 14, 9 07:01:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 03:49:11 -0000 Michael D'Errico wrote: > > > The more I think about it, the more I'm opposed to using > > TLS extensions to wrap this fix. It's just to urgent and serious > > to spend such an amount of time on a fancy wrapping. > > I'm OK with whatever the fix becomes, but just want to point out > that changing the Finished message calculation for renegotiations > does not protect a patched client when talking to an unpatched > server. The negotiation (=signaling C->S and more importantly S->C) in ClientHello and ServerHello is what clients can use to protect themselves. They can warn or decide to not talk to servers that are not patched at some point in the future. An warning popup is a suitable method to apply market pressure. A lack of interoperability is not a suitable method, it is rather a sign of poor engineering. All Browsers that added newer TLS versions and the TLS extension SNI also had to add an app-level reconnect fallback because of the resulting interop problems. If we wrap this fix into a TLS extension, then every recipient of that fix will encounter the very same interop problems as the Browser vendors/implementors. This will result in annoyed customers, many support calls, some apps will be enhanced to also add re-connect fallbacks, but overall it will significantly slow down the adoption of the patch -- instead, the workaround to take countermeasures to TLS renegotiation will then effectively kill renegotiation. I think it is neither reasonable nor justified to cause so much pain when it is possible to fix the problem with significantly less resulting interop problems by _NOT_ using a TLS extension. Side note: I do think we should add 1 page of guidance to implementors in the final document outlining what implementors should really check and fix when they touch code in order to implement the fix for TLS renegotiation. - how to correctly process a ClientHello with additional data (all protocol version SSLv3->TLSv1.2) - how to correctly process the protocol version fields in the handshake messages and record protocol. (but really only 1 page). -Martin From mike-list@pobox.com Sat Nov 14 20:06:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7653A6358 for ; Sat, 14 Nov 2009 20:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Du1ry-mhwvOK for ; Sat, 14 Nov 2009 20:06:58 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 1BFEB3A6359 for ; Sat, 14 Nov 2009 20:06:58 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 110C87FFFE for ; Sat, 14 Nov 2009 23:07:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=IVO0rU1wfg9h de2+dELMofinfpk=; b=V7NYEpcAOboRQCCL4El1vOrPSHdA+lPL8HgBdzdLQYw6 /19niD5i/loEY14AVSIluvg8tNoFlXouIEoYIvxWzy7Wo8PQc/6msK2tGypUJSw9 tN1oG3lrX+LE7jQOOOpPIC0AdvHzfWspdmDl9v4Dn0zHKtKHp7PZTBA9lssvY/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=S/9bQ/ n6HQ8w3FM1lHncRjvU3xBh+umXBYdec+HlET+hfUDdg1bgyXtsWViUMiyI1UnNlx +S3Mpkxbz8m5igVq1u1wh5hHsdiQhhmAtaLjMJGoftYLf8NdgrnMoRAaMzlqtdV6 EMmIVsjDhO4sy3okNVVPHStZSxMzvE/4rs+HU= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0DDA67FFFD for ; Sat, 14 Nov 2009 23:07:28 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 905037FFFC for ; Sat, 14 Nov 2009 23:07:27 -0500 (EST) Message-ID: <4AFF7EC3.8060805@pobox.com> Date: Sat, 14 Nov 2009 20:08:35 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> In-Reply-To: <4AFF77B1.1000106@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 63639B36-D19C-11DE-AA5F-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] A crazy idea X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 04:06:59 -0000 Here's a crazy idea: we could define a completely incompatible change to the way Finished messages are calculated even on initial handshakes. A client can initially try connecting using the new Finished message calculation, and if that fails, fall back to the original (if it's willing to risk talking to an unpatched server). The server has the advantage of receiving the client's Finished message before it needs to send its own, so it can compute both the new and the old versions to see which the client supports. Then it can decide whether to continue with the handshake or abort. This also thwarts any tampering by a MITM since neither calculation would match if messages were altered. For session resumption, each side would need to remember whether the new or the old Finished calculation was used. Just throwing the idea out there.... Mike From marsh@extendedsubset.com Sat Nov 14 20:17:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A73C3A6806 for ; Sat, 14 Nov 2009 20:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 GuhpISrGxA+v for ; Sat, 14 Nov 2009 20:17:35 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id CA5B43A67A8 for ; Sat, 14 Nov 2009 20:17:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9WYw-000Iyp-SF for tls@ietf.org; Sun, 15 Nov 2009 04:18:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B07BC6678 for ; Sun, 15 Nov 2009 04:18:05 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19PJD9/YaLWKb5kSkpK4U0iILV3cMYdcTE= Message-ID: <4AFF80FA.90106@extendedsubset.com> Date: Sat, 14 Nov 2009 22:18:02 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> <4AFF7EC3.8060805@pobox.com> In-Reply-To: <4AFF7EC3.8060805@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] A crazy idea X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 04:17:36 -0000 Michael D'Errico wrote: > Here's a crazy idea: we could define a completely incompatible change > to the way Finished messages are calculated even on initial handshakes. Or it could be as simple as flipping one bit in the verify_data. > A client can initially try connecting using the new Finished message > calculation, and if that fails, fall back to the original (if it's > willing to risk talking to an unpatched server). We can't change the app code. > The server has the advantage of receiving the client's Finished message > before it needs to send its own, so it can compute both the new and the > old versions to see which the client supports. Then it can decide > whether to continue with the handshake or abort. This also thwarts any > tampering by a MITM since neither calculation would match if messages > were altered. > > For session resumption, each side would need to remember whether the > new or the old Finished calculation was used. > > Just throwing the idea out there.... We need all the ideas we can get. Really, I think the harder problem is signaling in the initial hellos, particularly the server hello. We need one unambiguous bit in each direction, with a consistent default from unpatched endpoints. - Marsh From nelson@bolyard.me Sat Nov 14 20:47:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CD53A68D6 for ; Sat, 14 Nov 2009 20:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 NfRzWjJ6ztHf for ; Sat, 14 Nov 2009 20:47:37 -0800 (PST) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id B92163A68E8 for ; Sat, 14 Nov 2009 20:47:37 -0800 (PST) Received: (qmail 5643 invoked from network); 15 Nov 2009 04:48:07 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 15 Nov 2009 04:48:07 -0000 Message-ID: <4AFF887D.8030301@bolyard.me> Date: Sat, 14 Nov 2009 20:50:05 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> <4AFF7981.90804@extendedsubset.com> In-Reply-To: <4AFF7981.90804@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 04:47:38 -0000 On 2009-11-14 19:46 PDT, Marsh Ray wrote: > David-Sarah Hopwood wrote: >> Yes, but Michael's point was that changing the Finished message >> >> That's why a separate indication of patched status is needed > > Hi All, > > It's clear we're going to have to take a fresh look at this thing. What makes that clear? There will always be people with new/additional ideas, and always people who grumble about the chosen answer. Have we found an insurmountable obstacle? There are now something like 5 known interoperable implementations of EKR's draft. I think those of us with those implementations are essentially just waiting now for an official code point for the RI extension to be allocated by the IANA. Do we really want to toss all that for plan B? > I've worked up some additional requirements that we've come to > understand. To follow in its own email. OK, will read with interest. From mike-list@pobox.com Sat Nov 14 20:49:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040E93A6811 for ; Sat, 14 Nov 2009 20:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 f6Kir17rYEdZ for ; Sat, 14 Nov 2009 20:49:36 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 33BDD3A67AC for ; Sat, 14 Nov 2009 20:49:36 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 4B2EA9E374 for ; Sat, 14 Nov 2009 23:50:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=woCnzwBWXJaF 5JtLKaERDnmiDC4=; b=dTHhCatdqZEpmltDnRnekFU3IiXgZtvjHFSGFpRLn3Jo ufjB1uMSF02M+F+wVfdaOSrEAx9G7bzzxPVJaUoqg6MT4aGz4Ze3x8BR0QntY8iT fbZAbpxvVyW0aXNRVbaZcr7yDxrx+9r/DM0187jfcxfsNC027gVzmGxMMPOG6AI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=i91tyG 0DH8Ql+6mj0Su2HUUOBdlb0URt4xBh44OpYMjEkbcbv7YV2XWnTeq00E8E9sa0J5 3+hRAjS66ONBsdrDdnxskA11+VvilOEtMF6EPoeX4wzgnpx2Ryma8sN+WVBEMbs5 7zfNFLoKX3Uoyyqq7qwwlKRrbDaIyIeb21L08= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 4190E9E373 for ; Sat, 14 Nov 2009 23:50:07 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id BEF2F9E372 for ; Sat, 14 Nov 2009 23:50:06 -0500 (EST) Message-ID: <4AFF88C2.3030807@pobox.com> Date: Sat, 14 Nov 2009 20:51:14 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> <4AFF7EC3.8060805@pobox.com> <4AFF80FA.90106@extendedsubset.com> In-Reply-To: <4AFF80FA.90106@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 58C76580-D1A2-11DE-B98E-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] A crazy idea X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 04:49:37 -0000 There could be an initial roll-out of patched servers, configured to respond to both patched and unpatched clients, but to not perform renegotiation with unpatched clients. Once sufficient time has passed, patched clients can be rolled out, followed by turning off compatibility mode in servers. Clients that currently do not have reconnect logic would not need to add it. Mike Marsh Ray wrote: > Michael D'Errico wrote: >> Here's a crazy idea: we could define a completely incompatible change >> to the way Finished messages are calculated even on initial handshakes. > > Or it could be as simple as flipping one bit in the verify_data. > >> A client can initially try connecting using the new Finished message >> calculation, and if that fails, fall back to the original (if it's >> willing to risk talking to an unpatched server). > > We can't change the app code. > >> The server has the advantage of receiving the client's Finished message >> before it needs to send its own, so it can compute both the new and the >> old versions to see which the client supports. Then it can decide >> whether to continue with the handshake or abort. This also thwarts any >> tampering by a MITM since neither calculation would match if messages >> were altered. >> >> For session resumption, each side would need to remember whether the >> new or the old Finished calculation was used. >> >> Just throwing the idea out there.... > > We need all the ideas we can get. > > Really, I think the harder problem is signaling in the initial hellos, > particularly the server hello. We need one unambiguous bit in each > direction, with a consistent default from unpatched endpoints. > > - Marsh From ynir@checkpoint.com Sun Nov 15 02:23:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2A73A6944 for ; Sun, 15 Nov 2009 02:23:31 -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 NJw7vOYi0P+R for ; Sun, 15 Nov 2009 02:23:31 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A09C23A67DF for ; Sun, 15 Nov 2009 02:23:30 -0800 (PST) X-CheckPoint: {4AFFD373-6-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 44D2929C009; Sun, 15 Nov 2009 12:24:01 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2727F29C002; Sun, 15 Nov 2009 12:24:01 +0200 (IST) X-CheckPoint: {4AFFD373-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAFAO0c6012969; Sun, 15 Nov 2009 12:24:00 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 15 Nov 2009 12:24:06 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Sun, 15 Nov 2009 12:24:00 +0200 Thread-Topic: [TLS] Protected Renegotiation -- refined proposal Thread-Index: Acpl3cJrmVA5knp2Q82Xqt9nn2VOeg== Message-ID: <02BE2D88-E0DD-4C0D-A23C-BDAC35ABE53D@checkpoint.com> References: <200911150145.nAF1jZEf017404@fs4113.wdf.sap.corp> In-Reply-To: <200911150145.nAF1jZEf017404@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-12-800566669"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "tls@ietf.org list" Subject: Re: [TLS] Protected Renegotiation -- refined proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 10:23:31 -0000 --Apple-Mail-12-800566669 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Well, there was a suggestion a while back to use magic values for the = gmt_unix_time field. Peter Guttman added an important data point, that = some implementations already randomize this field, to avoid revealing = their incorrect system clock. This can definitely be used for S-->C signaling, while C-->S signaling = can either use the same field, or a special cipher-suite. (I'm wary of = using the gmt_unix_time field because there's only one of them - we = can't use it again for the next security bug) So yes, we can meet Marsh Ray's requirement that the signaling be done = without extensions. On Nov 15, 2009, at 3:45 AM, Martin Rex wrote: >=20 > What we should add to the protocol is the signaling of this protocol > change Client->Server and Server->Client through the ClientHello > and ServerHello handshake messages. The most interoperable signaling > C->S is a specially assigned ciphersuites ID, we probably do not need > to discuss that. I'm open to sugestions for the S->C signaling. > Since the Server will signal only when he sees the clients signal > in the ClientHello, you could at that point actually change the > ServerHello message. Changing the ServerHello is NOT going to > break anything here! --Apple-Mail-12-800566669 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExNTEw MjQwMVowIwYJKoZIhvcNAQkEMRYEFJPea3Ow0xjnZuiaQBvaagmia5kCMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQCLurXy2R3W djkluXBEbzNqf7N4km84A28gmvvx9fm+EBjkCM4+1CIW1u6ocl4w+vqlziylVR3Q14u5DLjv0CsS eY68/36eZxWi+dk4bI+HtVN3+T7ouooByAgNkDDSfz3qt/kQBRaWCgetxW69NK6LGYPsQqvhwVnj Nm83MvZlEkAt+eVKP8Gj4iKMG0lgGx8JWDxTgEb5u+zyh+VWqEYtszuD1OV9+cvsKdToFEXzPckx Kf7C37AgllEDv7zN+/+XxFpVBzTns8w/yWhmfC4b6tdQmtid0Xs5//Z6/+X6cltHJGq+Bv9dTrsW C0+CXz40lzNX93o2zqE2auyowVBLAAAAAAAA --Apple-Mail-12-800566669-- From jsalowey@cisco.com Sun Nov 15 03:12:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9833A6936 for ; Sun, 15 Nov 2009 03:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.662 X-Spam-Level: X-Spam-Status: No, score=-6.662 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 VCzBf3KW3sqL for ; Sun, 15 Nov 2009 03:12:31 -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 734803A68D4 for ; Sun, 15 Nov 2009 03:12:31 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJdw/0qrR7H+/2dsb2JhbAC7DZZnhDwE X-IronPort-AV: E=Sophos;i="4.44,746,1249257600"; d="scan'208";a="433052333" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 15 Nov 2009 11:13:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAFBD31Z018768 for ; Sun, 15 Nov 2009 11:13:03 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Nov 2009 03:13:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 03:13:01 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: To extend or not to extend Thread-Index: Acpl5Jg5KreSuv6HTUy/BpWTbGDRZA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 Nov 2009 11:13:03.0216 (UTC) FILETIME=[99497F00:01CA65E4] Subject: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 11:12:32 -0000 We need to close on this issue. To summarize the RI proposal (the draft submitted last week) has the following properties in various situations A. The RI proposal works fine if both client and server are patched. =20 B. The RI proposal works fine if the client is not patched and the server is (the server ends up disabling re-negotiation). =20 C. The RI proposal works fine if the client is patched and the server is not, if the server is implemented correctly.=20 D. The RI proposal works fine if the client is patched and the server does not implement the SSL 3.0 and the TLS 1.x specs correctly (barf if they see an extension) and the client desires to implement an secure policy and disallows connections to non patched servers E. The RI proposal has an issue if the client is patched and the server does not implement the SSL 3.0 and the TLS 1.x specs correctly and the client as a lenient policy which allows connection to insecure servers. In this case the client would have to implement some fallback logic (reconnect without extensions) to deal with broken servers. This logic is well-known, but it leaves a roll-back attack open. This can be plugged by using the proposed ciphersuite signal only in the case where extensions cause a handshake or connection failure. The fallback cipher-suite signaling for RI to prevent rollback extends TLS in an unexpected way, but this is limited only to the case where we have to deal with broken implementations. =20 Situation E is one that we expect to get less common because we want all implementations to get patched and clients may start requiring the fix because this is the only way they can protect themselves. =20 The ciphersuite-changes-handshake proposal has similar properties except we expect that there are few broken servers that will barf on an unknown ciphersuite (Situation E). This proposal extends TLS in a non-standard place by having the presence of a specific ciphersuite act as a side channel to change the behavior of the TLS handshake for all current versions of TLS. I don't think this is something that we would want to promote in the future, the code to handle this would be "one-off" code. >From a functional point of view I don't see any difference between A) RI extension with option ciphersuite signal in the case of fallback for broken servers and B) ciphersuite-changes-handshake proposal. =20 In TLS we have two standard ways of extending the functionality defined. One is extensions and one is the version number. Changing the version number is not really helpful at this point because it would require all systems to update to TLS 1.3 and its not clear that any of the situations above would change. Extensions are the way to extend the spec. Extensions are now part of the base specification and we want implementations to process extensions correctly even if they only support the RI fix. =20 I think it comes down to whether we want to extend TLS in a standard way for compliant implementations with a non-standard fallback behavior for handling non-compliant implementations or extend TLS in a non-standard way for all implementations. The standard vs. non-standard is somewhat nonsensical because we can make something standard with IETF consensus, however this will have implications on implementations and future extensions moving forward. =20 IMO, given that the two approaches are functionally equivalent I would prefer to extend things in the standard way.=20 From ekr@networkresonance.com Sun Nov 15 03:16:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D65C3A68D4 for ; Sun, 15 Nov 2009 03:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.108 X-Spam-Level: X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I86dRDn91nKf for ; Sun, 15 Nov 2009 03:16:52 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 204393A67CF for ; Sun, 15 Nov 2009 03:16:52 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9d6f-0005zL-00 for tls@ietf.org; Sun, 15 Nov 2009 13:17:21 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 334A869F79B; Sun, 15 Nov 2009 13:18:34 +0200 (EET) Date: Sun, 15 Nov 2009 13:18:33 +0200 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4AFF79A4.6020706@extendedsubset.com> References: <4AFF79A4.6020706@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115111834.334A869F79B@kilo.networkresonance.com> Cc: "tls@ietf.org" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 11:16:54 -0000 At Sat, 14 Nov 2009 21:46:44 -0600, Marsh Ray wrote: > > > The current draft-rescorla-tls-renegotiation represents a good solution, > at least from the theoretical perspective. However, when one begins to > consider the practical difficulties it is encountering in actual > deployment it becomes clear that it is not likely to be a good solution > in practice. That's not at all clear to me. > It is for this reason that we need to look at other > proposals with the aim of providing the most compatible and easiest to > implement fix on existing systems. > > This means: > > === R5. Not using an extension to implement the fix. > > Currently there are no examples of extensions used in a critical role > between interoperable systems, even where there would be significant > gain (financial and otherwise) from their use (e.g., SNI). An urgent > security-critical bug fix is absolutely not the place for blazing new > trails. I don't find this convincing at all. There's a huge difference between using an extension to implement something which we know needs changes on both sides right now and which we want to break if both sides aren't changed and using an extension to roll out an incremental feature that's a nice to have (i.e., name-based virtual hosting.) I think it might be useful to go back to first principles: 1. Servers which do not wish to do renegotiation can protect themselves without any change to the TLS protocol or to the client. I think it's pretty clearly desirable to have such servers continue to work with downrev clients. 2. Any fix must cause renegotiation between upgraded and unupgraded agents to fail. This is true whether the fix is explicitly signalled via an extension, explicitly signalled via a cipher suite/version, or unsignaled, such as by extending the finished message hash to incorporate earlier handshakes/incorporating previous finished messages into the PRF. Thus, the minimal change is not to change initial negotiations at all but simply to change renegotiations. This is quite possible with RI simply by not sending it on the initial negotiation. Of course, sending it on renegotiation will cause interoperation failure with vulnerable servers, but that's the desired outcome. 3. If we only make the minimal change, then clients will not be able to determine whether they are connecting to a vulnerable server even if they have no intention of renegotiating. If we want them to be able to do so, then it's most natural to have upgraded servers behave differently on the initial negotiation. I should add that I don't really think this functionality is that useful. Because the simplest fix is to simply disable renegotiation, many servers will do just that, regardless of how compatible the client's offer of a newer version is. I find it highly implausible that people who are currently running OpenSSL 0.9.7x are going to suddenly install a version which responds to a fake cipher suite by upgrading to TLS version 1.3! Thus, any client which warns on failure of the server to acknowledge being upgraded is going to be throwing off a huge number of false positives. Per (1) I think it's desirable to not have this functionality break un-upgraded clients. Similarly, it should be possible for upgraded clients which don't care about whether servers are upgraded to be able to interoperate with such servers (which, again, will dominate for the foreseeable future). As I indicated above, this is trivially possible with RI simply by not sending it on the initial negotiation: there's no interop problem but the client doesn't learn anything. And again, RI can always be used on subsequent negotiations. For clients who care, there are a number of mechanisms we could use to provide this functionality, including: (a) Send RI on the initial handshake. (b) Send something else (e.g., a fake cipher suite) on the initial handshake. (c) Have the server send something unsolicited, e.g., a fixed portion of the ServerRandom. The major problem (to the extent it is a problem) with offering RI on the initial handshake is that it may cause interop failures with some servers which don't support TLS extensions properly. In order for this to be an issue however, you have to believe that: (1) The client wishes to be able to detect that servers have not been upgraded. (2) The client isn't going to outright fail when it encounters such servers. (3) The client can't deal with a reconnect given (2) and (3). I don't really find this set of assumptions very plausible. Clients which care enough to actually probe the server to determine if it has been upgraded need to do something with that information. If they're going to outright fail then there's no problem here: they might as well fail when the server chokes on the extension as fail when they detect that the server isn't upgraded. If they're going to pop up a warning dialog (a bad idea in any case because of warning exhaustion) then I don't see that a reconnect is that big a problem, since they've already had to engage a bunch of application logic. And remember that this question *only* applies to servers which don't properly handle extensions. Given that the fix to do so is trivial (just ignore data after the ClientHello), and those servers are most likely vulnerable in any case, I really don't see that this is a major issue. 4. The other argument offered in favor of avoiding extensions is that we want to be able to provide upgraded SSLv3 implementations. I'm unconvinced that there are a significant number of applications which: (1) Can't use TLS. (2) Do renegotiation. (3) Are going to upgrade their stacks to support some new secure renegotiation thing change. (4) Won't just upgrade to TLS. Certainly all the major stack vendors have had TLS support for a very long time. For instance, you have to go back to before OpenSSL even existed to find a version of SSLeay that is SSLv3 only. And if you do support TLS, the effort of just implementing doing this extension is really not significantly greater than the other proposed fixes. -Ekr From ekr@networkresonance.com Sun Nov 15 03:17:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EB73A6952 for ; Sun, 15 Nov 2009 03:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.108 X-Spam-Level: X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AltddTeAiiBP for ; Sun, 15 Nov 2009 03:17:00 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id EC0353A6960 for ; Sun, 15 Nov 2009 03:16:59 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9d6o-00068R-00 for tls@ietf.org; Sun, 15 Nov 2009 13:17:30 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 6784369F79C; Sun, 15 Nov 2009 13:18:45 +0200 (EET) Date: Sun, 15 Nov 2009 13:18:45 +0200 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4AFF79A4.6020706@extendedsubset.com> References: <4AFF79A4.6020706@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115111845.6784369F79C@kilo.networkresonance.com> Cc: "tls@ietf.org" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 11:17:01 -0000 At Sat, 14 Nov 2009 21:46:44 -0600, Marsh Ray wrote: > > > The current draft-rescorla-tls-renegotiation represents a good solution, > at least from the theoretical perspective. However, when one begins to > consider the practical difficulties it is encountering in actual > deployment it becomes clear that it is not likely to be a good solution > in practice. That's not at all clear to me. > It is for this reason that we need to look at other > proposals with the aim of providing the most compatible and easiest to > implement fix on existing systems. > > This means: > > === R5. Not using an extension to implement the fix. > > Currently there are no examples of extensions used in a critical role > between interoperable systems, even where there would be significant > gain (financial and otherwise) from their use (e.g., SNI). An urgent > security-critical bug fix is absolutely not the place for blazing new > trails. I don't find this convincing at all. There's a huge difference between using an extension to implement something which we know needs changes on both sides right now and which we want to break if both sides aren't changed and using an extension to roll out an incremental feature that's a nice to have (i.e., name-based virtual hosting.) I think it might be useful to go back to first principles: 1. Servers which do not wish to do renegotiation can protect themselves without any change to the TLS protocol or to the client. I think it's pretty clearly desirable to have such servers continue to work with downrev clients. 2. Any fix must cause renegotiation between upgraded and unupgraded agents to fail. This is true whether the fix is explicitly signalled via an extension, explicitly signalled via a cipher suite/version, or unsignaled, such as by extending the finished message hash to incorporate earlier handshakes/incorporating previous finished messages into the PRF. Thus, the minimal change is not to change initial negotiations at all but simply to change renegotiations. This is quite possible with RI simply by not sending it on the initial negotiation. Of course, sending it on renegotiation will cause interoperation failure with vulnerable servers, but that's the desired outcome. 3. If we only make the minimal change, then clients will not be able to determine whether they are connecting to a vulnerable server even if they have no intention of renegotiating. If we want them to be able to do so, then it's most natural to have upgraded servers behave differently on the initial negotiation. I should add that I don't really think this functionality is that useful. Because the simplest fix is to simply disable renegotiation, many servers will do just that, regardless of how compatible the client's offer of a newer version is. I find it highly implausible that people who are currently running OpenSSL 0.9.7x are going to suddenly install a version which responds to a fake cipher suite by upgrading to TLS version 1.3! Thus, any client which warns on failure of the server to acknowledge being upgraded is going to be throwing off a huge number of false positives. Per (1) I think it's desirable to not have this functionality break un-upgraded clients. Similarly, it should be possible for upgraded clients which don't care about whether servers are upgraded to be able to interoperate with such servers (which, again, will dominate for the foreseeable future). As I indicated above, this is trivially possible with RI simply by not sending it on the initial negotiation: there's no interop problem but the client doesn't learn anything. And again, RI can always be used on subsequent negotiations. For clients who care, there are a number of mechanisms we could use to provide this functionality, including: (a) Send RI on the initial handshake. (b) Send something else (e.g., a fake cipher suite) on the initial handshake. (c) Have the server send something unsolicited, e.g., a fixed portion of the ServerRandom. The major problem (to the extent it is a problem) with offering RI on the initial handshake is that it may cause interop failures with some servers which don't support TLS extensions properly. In order for this to be an issue however, you have to believe that: (1) The client wishes to be able to detect that servers have not been upgraded. (2) The client isn't going to outright fail when it encounters such servers. (3) The client can't deal with a reconnect given (2) and (3). I don't really find this set of assumptions very plausible. Clients which care enough to actually probe the server to determine if it has been upgraded need to do something with that information. If they're going to outright fail then there's no problem here: they might as well fail when the server chokes on the extension as fail when they detect that the server isn't upgraded. If they're going to pop up a warning dialog (a bad idea in any case because of warning exhaustion) then I don't see that a reconnect is that big a problem, since they've already had to engage a bunch of application logic. And remember that this question *only* applies to servers which don't properly handle extensions. Given that the fix to do so is trivial (just ignore data after the ClientHello), and those servers are most likely vulnerable in any case, I really don't see that this is a major issue. 4. The other argument offered in favor of avoiding extensions is that we want to be able to provide upgraded SSLv3 implementations. I'm unconvinced that there are a significant number of applications which: (1) Can't use TLS. (2) Do renegotiation. (3) Are going to upgrade their stacks to support some new secure renegotiation thing change. (4) Won't just upgrade to TLS. Certainly all the major stack vendors have had TLS support for a very long time. For instance, you have to go back to before OpenSSL even existed to find a version of SSLeay that is SSLv3 only. And if you do support TLS, the effort of just implementing doing this extension is really not significantly greater than the other proposed fixes. -Ekr From ekr@networkresonance.com Sun Nov 15 03:37:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15B03A6904 for ; Sun, 15 Nov 2009 03:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82NASGelL66J for ; Sun, 15 Nov 2009 03:37:12 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id B8C8F3A67C1 for ; Sun, 15 Nov 2009 03:37:11 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9dQM-0002bO-00 for tls@ietf.org; Sun, 15 Nov 2009 13:37:42 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 4E04D69F7B2; Sun, 15 Nov 2009 13:38:57 +0200 (EET) Date: Sun, 15 Nov 2009 13:38:57 +0200 From: Eric Rescorla To: "Joseph Salowey (jsalowey)" In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 11:37:13 -0000 At Sun, 15 Nov 2009 03:13:01 -0800, Joseph Salowey (jsalowey) wrote: > > We need to close on this issue. To summarize the RI proposal (the draft > submitted last week) has the following properties in various situations > > > A. The RI proposal works fine if both client and server are patched. > > B. The RI proposal works fine if the client is not patched and the > server is (the server ends up disabling re-negotiation). > > C. The RI proposal works fine if the client is patched and the server is > not, if the server is implemented correctly. > > D. The RI proposal works fine if the client is patched and the server > does not implement the SSL 3.0 and the TLS 1.x specs correctly (barf if > they see an extension) and the client desires to implement an secure > policy and disallows connections to non patched servers > > E. The RI proposal has an issue if the client is patched and the server > does not implement the SSL 3.0 and the TLS 1.x specs correctly and the > client as a lenient policy which allows connection to insecure servers. > In this case the client would have to implement some fallback logic > (reconnect without extensions) to deal with broken servers. This logic > is well-known, but it leaves a roll-back attack open. This can be > plugged by using the proposed ciphersuite signal only in the case where > extensions cause a handshake or connection failure. The fallback > cipher-suite signaling for RI to prevent rollback extends TLS in an > unexpected way, but this is limited only to the case where we have to > deal with broken implementations. So, thinking further on my earlier message, I think the following elaboration will work a bit better: - Strict clients (those which wish to insist on RI) generate RI on initial handshake. As I said earlier, I don't think this is useful, but it works. - Lenient clients do not generate RI on initial handshake but do generate it on rehandshake with TLS 1.0+ only. + Moderately lenient clients can fail if the server does not do RI. + Really lenient clients can ignore the server's failure to do RI. This has the following advantages: For all non-renegotiated settings you get exactly the same interop properties you ordinarily would. I.e., it just works. With renegotiation, you get an extremely high interop probability even if the server has not upgraded because compliant TLS implementations are required to at worst ignore extensions (RFC 2246; S 7.4.1.2), and you've already weeded out SSLv3-only implementations in the initial handshake. Now, there is still arguably a downgrade attack because the attacker can simulate a completely broken SSLv3 stack and force you down to SSLv3 in the initial handshake (they can't do it in later handshakes because those are protected). Note, however, that since we're not exercising the extension logic in that handshake (though of course the client may be exercising it for some other reason, say if it's doing SNI), the server the attacker is simulating has to be really broken because it's not handling version number negotiation correctly. However, we can still use a cipher suite indicator if we think it's absolutely necessary to allow fallback to SSLv3 here. -Ekr From Nicolas.Williams@sun.com Sun Nov 15 09:43:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0289A3A69A4 for ; Sun, 15 Nov 2009 09:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[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 vc2T0nhNlJXa for ; Sun, 15 Nov 2009 09:43:37 -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 29B6A3A67AB for ; Sun, 15 Nov 2009 09:43:35 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAFHhYCG001199 for ; Sun, 15 Nov 2009 17:43:34 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 nAFHhY68040390 for ; Sun, 15 Nov 2009 10:43: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 nAFHVw3x021018; Sun, 15 Nov 2009 11:31:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAFHVwdt021017; Sun, 15 Nov 2009 11:31:58 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 15 Nov 2009 11:31:57 -0600 From: Nicolas Williams To: "Michael D'Errico" Message-ID: <20091115173157.GR1105@Sun.COM> References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> <4AFF7EC3.8060805@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFF7EC3.8060805@pobox.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] A crazy idea X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 17:43:38 -0000 On Sat, Nov 14, 2009 at 08:08:35PM -0800, Michael D'Errico wrote: > Here's a crazy idea: we could define a completely incompatible change > to the way Finished messages are calculated even on initial handshakes. Not on initial. My proposal is to do it only on re-negotiate. From bmoeller@acm.org Sun Nov 15 09:59:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0423A69CF for ; Sun, 15 Nov 2009 09:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.649 X-Spam-Level: X-Spam-Status: No, score=-99.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 AfPHXjmdErZ5 for ; Sun, 15 Nov 2009 09:59:29 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 168333A69C7 for ; Sun, 15 Nov 2009 09:59:29 -0800 (PST) Received: from [192.168.1.3] (c-76-102-12-92.hsd1.ca.comcast.net [76.102.12.92]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MFQw8-1NO5NN30Q0-00ExFF; Sun, 15 Nov 2009 18:59:25 +0100 From: Bodo Moeller To: Eric Rescorla In-Reply-To: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> References: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> Message-Id: <0D465614-FD0D-48AC-9311-F7A48E17351E@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 09:59:19 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX18EV2GERnWKg5GMC3slhsaHvtcpojit3Kuz/XG 3zxlGXafaN/4TVV5HZZIDiABqBUx98kVUvPJzECWHGUJPqyn4c ZU4wSUzT+SY2orYSpyOKw== Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 17:59:30 -0000 On Nov 15, 2009, at 3:38 AM, Eric Rescorla wrote: > So, thinking further on my earlier message, I think the following > elaboration will work a bit better: > > - Strict clients (those which wish to insist on RI) generate RI on > initial handshake. As I said earlier, I don't think this is > useful, but it works. > > - Lenient clients do not generate RI on initial handshake but do > generate it on rehandshake with TLS 1.0+ only. > + Moderately lenient clients can fail if the server does not > do RI. > + Really lenient clients can ignore the server's failure to > do RI. Yes, please. I was going to send an email asking for this, but you beat me at it. Bodo From bmoeller@acm.org Sun Nov 15 10:24:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050603A67D7 for ; Sun, 15 Nov 2009 10:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.649 X-Spam-Level: X-Spam-Status: No, score=-99.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 7LY+YFlseO5u for ; Sun, 15 Nov 2009 10:24:17 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 025E93A67AB for ; Sun, 15 Nov 2009 10:24:16 -0800 (PST) Received: from [192.168.1.3] (c-76-102-12-92.hsd1.ca.comcast.net [76.102.12.92]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lkzvp-1NkRUr0Ss1-00bMB7; Sun, 15 Nov 2009 19:24:01 +0100 From: Bodo Moeller To: mrex@sap.com In-Reply-To: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp> References: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp> Message-Id: <82B3FF62-B9AE-45D0-AB6A-62ACACFC3F97@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 10:23:57 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX19f3WBYlcB3wFsdcleF5UIL6GFngWsQe4T5VOp aoHfEH/HUYSkcROmX54EAzLPlRn42ayGQCd5rirhOQJp4CxEr6 N/a2gWEid1dk6sxWJFvrw== Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 18:24:18 -0000 On Nov 11, 2009, at 9:12 PM, Martin Rex wrote: > Marsh Ray wrote: >> >> SSL 3.0 doesn't seem to allow extensions on Server and Client Hello >> messages. > > That is wrong. The SSLv3 spec has the exact same provisions for > TLS extensions as the TLSv1.0 and TLSv1.1 specs. > > TLS extensions became a standard part of the protocol in TLSv1.2 only. > > Compare the specs and you will see. Can you be more specific? The "Client hello" section in RFC2246 (i.e., for TLS 1.0) includes a "Forward compatibility note": "In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods." This is the provision that allows clients to try using extensions without having to know whether a specific server has extension support. I can't spot something like that in draft-freier-ssl-version3-01.txt. What wording in what specification are you referring to? Bodo From marsh@extendedsubset.com Sun Nov 15 10:36:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5993A69EE for ; Sun, 15 Nov 2009 10:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juvAaZnZoRaz for ; Sun, 15 Nov 2009 10:36:24 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 5DA923A6778 for ; Sun, 15 Nov 2009 10:36:24 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9jxX-0002BQ-H3; Sun, 15 Nov 2009 18:36:23 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 67F3F667C; Sun, 15 Nov 2009 18:36:22 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19W4UyD8tIOZHGBHtgXTfXfRRgyHHRzLbk= Message-ID: <4B004A24.9080508@extendedsubset.com> Date: Sun, 15 Nov 2009 12:36:20 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bodo Moeller , tls@ietf.org References: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp> <82B3FF62-B9AE-45D0-AB6A-62ACACFC3F97@acm.org> In-Reply-To: <82B3FF62-B9AE-45D0-AB6A-62ACACFC3F97@acm.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 18:36:25 -0000 Bodo Moeller wrote: > > The "Client hello" section in RFC2246 (i.e., for TLS 1.0) includes a > "Forward compatibility note": "In the interests of forward > compatibility, it is permitted for a client hello message to include > extra data after the compression methods." This is the provision that > allows clients to try using extensions without having to know whether a > specific server has extension support. > > I can't spot something like that in draft-freier-ssl-version3-01.txt. > What wording in what specification are you referring to? This language only seems to be in the definition of the Client Hello, not the v3 Server Hello. - Marsh > Transport Layer Security Working Group Alan O. Freier > INTERNET-DRAFT Netscape Communications > Expire in six months Philip Karlton > Netscape Communications > Paul C. Kocher > Independent Consultant > November 18, 1996 > > The SSL Protocol > Version 3.0 > > > [...] > Forward compatibility note: > In the interests of forward compatibility, it is > permitted for a client hello message to include > extra data after the compression methods. This data > must be included in the handshake hashes, but must > otherwise be ignored. From jsalowey@cisco.com Sun Nov 15 10:39:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA0A3A68C3 for ; Sun, 15 Nov 2009 10:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 yH8iVpow9LJs for ; Sun, 15 Nov 2009 10:39:38 -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 42BF73A6894 for ; Sun, 15 Nov 2009 10:39:14 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABXa/0qrR7Ht/2dsb2JhbAC7XJZHhDwEgW0 X-IronPort-AV: E=Sophos;i="4.44,747,1249257600"; d="scan'208";a="433184924" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 15 Nov 2009 18:39:14 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAFIdEa9008941; Sun, 15 Nov 2009 18:39:14 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.3959); Sun, 15 Nov 2009 10:39:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 10:39:12 -0800 Message-ID: In-Reply-To: <4B004A24.9080508@extendedsubset.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3 Thread-Index: AcpmIop1JcW/I8VLQsmtjDFOV2R6LAAAEUKw References: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp><82B3FF62-B9AE-45D0-AB6A-62ACACFC3F97@acm.org> <4B004A24.9080508@extendedsubset.com> From: "Joseph Salowey (jsalowey)" To: "Marsh Ray" , "Bodo Moeller" , X-OriginalArrivalTime: 15 Nov 2009 18:39:13.0977 (UTC) FILETIME=[EDE77290:01CA6622] Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 18:39:39 -0000 =20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Marsh Ray > Sent: Sunday, November 15, 2009 10:36 AM > To: Bodo Moeller; tls@ietf.org > Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 >=20 > Bodo Moeller wrote: > > > > The "Client hello" section in RFC2246 (i.e., for TLS 1.0)=20 > includes a=20 > > "Forward compatibility note": "In the interests of forward=20 > > compatibility, it is permitted for a client hello message=20 > to include=20 > > extra data after the compression methods." This is the=20 > provision that=20 > > allows clients to try using extensions without having to=20 > know whether=20 > > a specific server has extension support. > >=20 > > I can't spot something like that in=20 > draft-freier-ssl-version3-01.txt.=20 > > What wording in what specification are you referring to? >=20 > This language only seems to be in the definition of the=20 > Client Hello, not the v3 Server Hello. >=20 [Joe] The server is not allowed to send an extension if the client does not send it. I don't see a spec problem here. =20 > - Marsh >=20 > > Transport Layer Security Working Group =20 > Alan O. Freier > > INTERNET-DRAFT Netscape=20 > Communications > > Expire in six months =20 > Philip Karlton > > Netscape=20 > Communications > > =20 > Paul C. Kocher > > Independent=20 > Consultant > > =20 > November 18, 1996 > >=20 > > The SSL Protocol > > Version 3.0 > >=20 > >=20 > > > [...] > > Forward compatibility note: > > In the interests of forward compatibility, it is > > permitted for a client hello message to include > > extra data after the compression methods.=20 > This data > > must be included in the handshake hashes, but must > > otherwise be ignored. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From mike-list@pobox.com Sun Nov 15 10:39:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEB43A67B4 for ; Sun, 15 Nov 2009 10:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU-awXeLvw0S for ; Sun, 15 Nov 2009 10:39:38 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id AB0663A69F1 for ; Sun, 15 Nov 2009 10:38:49 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 089259E700 for ; Sun, 15 Nov 2009 13:38:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=f1E1qRqMJIsv fWjDOEHIbEG0068=; b=Zsk3TLlTeUHAPVgFB3ZxRNMY+h6Ne57LGtPotxbXM81m vKW5q1tIBKpDZauhZksxaCj3G+3iX4ArdZpJfl0Fvhl/r6m2f++GrCl6N4N/e31X fOKDPh7eDcduDHcbdIs+MfXxfLurp2Bh3+QSzsaXYPwQtoOhMcfHq3AsJfWe2Lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=pWIKbN odfnhGD+yaWeMJ17wOKhsnAB6pV1bUZUWB9hOGPU6VyPYg3Sl2gLgHIyKBGzgn3y ZACLiHpjHnVoXSszmlLNBo4GAU6PScj5EjoSZih/KEkvzEYXZhLfOmO8K4RZlFFQ 3vpzt0BJkStMFjd03UdIk/uxlgrcnO0zwEG9c= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 04A589E6FF for ; Sun, 15 Nov 2009 13:38:48 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 735F69E6FE for ; Sun, 15 Nov 2009 13:38:47 -0500 (EST) Message-ID: <4B004AE7.9000305@pobox.com> Date: Sun, 15 Nov 2009 10:39:35 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> <4AFF7EC3.8060805@pobox.com> <20091115173157.GR1105@Sun.COM> In-Reply-To: <20091115173157.GR1105@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 1CAA7FB4-D216-11DE-8A99-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] A not-so crazy idea X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 18:39:39 -0000 Nicolas Williams wrote: > On Sat, Nov 14, 2009 at 08:08:35PM -0800, Michael D'Errico wrote: >> Here's a crazy idea: we could define a completely incompatible change >> to the way Finished messages are calculated even on initial handshakes. > > Not on initial. My proposal is to do it only on re-negotiate. Doing it on initial is necessary to protect clients when the server is not patched. Remember that the attack happens on the client's INITIAL handshake! We need to protect that handshake, and no other proposal does that reliably. Simply finishing the initial handshake completes the attack. Modifying the Finished calculation provides protection, but the best part is that an upgraded server can reliably detect the following three cases: 1) client is unpatched 2) client is patched 3) a MITM tampered with the handshake The server calculates both the old and the new client verify_data to see which one matches. If it matches the old (current) calculation, then the server knows the client is not upgraded (case 1) and it will not allow any renegotiations -- if this handshake IS a renegotiation, then there is a MITM possible, so the renegotiation is refused. If the client's verify data matches the new Finished calculation, then the handshake is allowed to complete whether it is an initial handshake or a renegotiation. (The new verify_data would incorporate channel binding info akin to the proposed RI extension.) If neither matches, then there was tampering by a MITM. Problems with RI: The RI extension is attackable in many ways by a MITM. It can be stripped from the ClientHello or stripped from ServerHello. If one side or the other makes decisions based on the presence or absence of the extension, then the MITM can control your behavior. The MITM can simulate a server "crash" by not forwarding the ServerHello, forging a fatal alert, or just closing the connection. And as has been pointed out there are numerous problems with requiring an implementation to add support for extensions, and may not be possible if the code only does SSLv3. Changing the Finished calculation is much better since there is no other change to the handshake, and does not modify anything about the bits on the wire. This is much more resistant to tampering by a MITM, and the server can reliably detect it! I think this is not such a crazy idea and should be given consideration. Mike From bmoeller@acm.org Sun Nov 15 10:40:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738183A6811 for ; Sun, 15 Nov 2009 10:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.949 X-Spam-Level: X-Spam-Status: No, score=-100.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ctrU6+ZK5yuz for ; Sun, 15 Nov 2009 10:40:07 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 6F4AD3A67AB for ; Sun, 15 Nov 2009 10:40:07 -0800 (PST) Received: from [192.168.1.3] (c-76-102-12-92.hsd1.ca.comcast.net [76.102.12.92]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0M8pIq-1NLs1I2ph6-00ClEE; Sun, 15 Nov 2009 19:39:58 +0100 Message-Id: <9184B7E2-EAB6-477E-AE0C-93BF858CC7EE@acm.org> From: Bodo Moeller To: Bodo Moeller In-Reply-To: <82B3FF62-B9AE-45D0-AB6A-62ACACFC3F97@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 10:39:54 -0800 References: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp> <82B3FF62-B9AE-45D0-AB6A-62ACACFC3F97@acm.org> X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX180xicxW16KURkL7sOMS9rvgWpGZOO1PU2fNhW 0Qke3tmm0s6CkWaYBRLVi63DovNIleUUflf83+JB8wNRQDrkCR Mg0FhdSb+0LWIRJpCRttA== Cc: tls@ietf.org Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 18:40:08 -0000 On Nov 15, 2009, at 10:23 AM, Bodo Moeller wrote: > On Nov 11, 2009, at 9:12 PM, Martin Rex wrote: >> Marsh Ray wrote: >>> >>> SSL 3.0 doesn't seem to allow extensions on Server and Client Hello >>> messages. >> >> That is wrong. The SSLv3 spec has the exact same provisions for >> TLS extensions as the TLSv1.0 and TLSv1.1 specs. >> >> TLS extensions became a standard part of the protocol in TLSv1.2 >> only. >> >> Compare the specs and you will see. > > Can you be more specific? > > The "Client hello" section in RFC2246 (i.e., for TLS 1.0) includes a > "Forward compatibility note": "In the interests of forward > compatibility, it is permitted for a client hello message to include > extra data after the compression methods." This is the provision > that allows clients to try using extensions without having to know > whether a specific server has extension support. > > I can't spot something like that in draft-freier-ssl- > version3-01.txt. What wording in what specification are you > referring to? Oh, never mind, I've seen some pointers in Marsh's follow-up message (under a different "Subject" header) -- the forward compatibility note was added after that -01 draft. Curiously, tools.ietf.org doesn't know of draft-freier-ssl- version3-02.txt, but has draft-ietf-tls-ssl-version3-00.txt from the same date (November 18, 1996). (For reference, draft-freier-ssl- version3-01.txt is from March 1996; draft-freier-ssl-version3-00.txt is from December 1995.) Bodo From mrex@sap.com Sun Nov 15 11:13:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787B83A69E4 for ; Sun, 15 Nov 2009 11:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 S9QT76dGJmMb for ; Sun, 15 Nov 2009 11:13:24 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 57E4C3A69F6 for ; Sun, 15 Nov 2009 11:13:24 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAFJDJfx007300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 20:13:19 +0100 (MET) From: Martin Rex Message-Id: <200911151913.nAFJDIHA015276@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joseph Salowey) Date: Sun, 15 Nov 2009 20:13:18 +0100 (MET) In-Reply-To: from "Joseph Salowey" at Nov 15, 9 03:13:01 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:13:28 -0000 First of all, please keep in mind that server that do not implement renegotiation have never been vulnerable in the first place. The only thing that those would have to add is the signaling on the initial handshake. They don't need to be able to exchange finished messages and neither do they need to change their finished message calculation. Just recognizing the clients signal and back-signaling "don't worry, I'm a nice server" is all they ever need to patch. Joseph Salowey wrote: > > We need to close on this issue. To summarize the RI proposal (the draft > submitted last week) has the following properties in various situations > > > A. The RI proposal works fine if both client and server are patched. > > B. The RI proposal works fine if the client is not patched and the > server is (the server ends up disabling re-negotiation). > > C. The RI proposal works fine if the client is patched and the server is > not, if the server is implemented correctly. That is an extremely huge if. It is currently extremely unsafe to send an extension in the ClientHello, therefore I'm extremely reluctant to add this to our client codebase, because our apps do not have a reconnect fallback. > > D. The RI proposal works fine if the client is patched and the server > does not implement the SSL 3.0 and the TLS 1.x specs correctly (barf if > they see an extension) and the client desires to implement an secure > policy and disallows connections to non patched servers This policy would mean that you brick the entire installed base, including those that have never been vulnerable. > > E. The RI proposal has an issue if the client is patched and the server > does not implement the SSL 3.0 and the TLS 1.x specs correctly and the > client as a lenient policy which allows connection to insecure servers. > In this case the client would have to implement some fallback logic > (reconnect without extensions) to deal with broken servers. This logic > is well-known, but it leaves a roll-back attack open. This can be > plugged by using the proposed ciphersuite signal only in the case where > extensions cause a handshake or connection failure. The fallback > cipher-suite signaling for RI to prevent rollback extends TLS in an > unexpected way, but this is limited only to the case where we have to > deal with broken implementations. > > Situation E is one that we expect to get less common because we want all > implementations to get patched and clients may start requiring the fix > because this is the only way they can protect themselves. Situation E is the Killer for the TLS extension RI. You can not seriously propose that people add reconnect fallbacks to all their applications in order to be able to use TLS extension RI in their clients during the transittion period and then after the transition period ask the apps to dump that huge amounts of code they had to implement because it is also a security problem. With the current installed base, using TLS extension to wrap the fix is a non-starter. > > The ciphersuite-changes-handshake proposal has similar properties except > we expect that there are few broken servers that will barf on an unknown > ciphersuite (Situation E). This proposal extends TLS in a non-standard > place by having the presence of a specific ciphersuite act as a side > channel to change the behavior of the TLS handshake for all current > versions of TLS. I don't think this is something that we would want to > promote in the future, the code to handle this would be "one-off" code. > > From a functional point of view I don't see any difference between A) RI > extension with option ciphersuite signal in the case of fallback for > broken servers and B) ciphersuite-changes-handshake proposal. If we use signaling through special ciphersuite ID, then we do not need the TLS extension anymore. The real problem of the TLS extension RI is the presence of the TLS extension on the initial handshake. If you remove the TLS extension RI from the ClientHello of the initial handshake, then the interop problems will go away. Only the superfluous waste of network bandwidth on the renegotiation remains. > > In TLS we have two standard ways of extending the functionality defined. > One is extensions and one is the version number. Excuse me, the Internet user do _NOT_ want us to make bold experiments and play around with extensions. They want us to fix a problem in the protocol that has been there for a very long time. If the SSL renegotiation had been designed correctly from the beginning, noone would have come to the idea to invent and use a SSL or TLS extension for this. One would have added the finished messages of the previous handshake into the handshake message hash of renegotiation handshake. It is simple and straightforward to apply the fix to the protocol, it creates significantly less interop problems with the installed base and does not waste and network bandwidth. And we want to only use the secure renegotiation in the future, so there is absolutely no problem in getting that "new code path" work correctly. I assume that my proposal is 50 lines of code at most. > > Changing the version number is not really helpful at this point > because it would require all systems to update to TLS 1.3 and > its not clear that any of the situations above would change. Huh? What are you talking about? My proposal works just fine with SSLv3 (0x03,0x00), noone will need to upgrade anything. But for TLSv1.3, we should no longer support the old renegotiation. This is why the extension, which will stick around for eternity, looks pretty awful, continuing nuisance and unnecessary waste of network bandwidth. > Extensions are the way to extend the spec. > Extensions are now part of the base specification and we want > implementations to process extensions correctly even if they only > support the RI fix. We do NOT NEED and extension for TLSv1.2. We urgently need a _FIX_ for all deployed protocol versions, including SSLv3, TLSv1.0 and TLSv1.1. Please stop refering to the fix as an extension, it is not an extension, and should not be described as one (and IMHO also not wrapped as one on the network). -Martin From bmoeller@acm.org Sun Nov 15 11:14:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E453A68C3 for ; Sun, 15 Nov 2009 11:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.082 X-Spam-Level: X-Spam-Status: No, score=-100.082 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 DZMe2yLIpfyI for ; Sun, 15 Nov 2009 11:14:49 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by core3.amsl.com (Postfix) with ESMTP id 37B9F28C0DB for ; Sun, 15 Nov 2009 11:13:57 -0800 (PST) Received: from [192.168.1.3] (c-76-102-12-92.hsd1.ca.comcast.net [76.102.12.92]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lv6ko-1O9znb24n4-010SnI; Sun, 15 Nov 2009 20:13:51 +0100 From: Bodo Moeller To: Nelson B Bolyard In-Reply-To: <4AFF0153.3090005@bolyard.me> References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <4AFF0153.3090005@bolyard.me> Message-Id: <3EFE80FB-AB07-4BB3-ABDD-E836D27B7E54@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 11:13:46 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX19NGDnbKM6dCB/5iwL7RGDvX7oWP4HXWUTNYM9 xJNUhn/abH3hcF4r/0yxn5pebQ1bRmRibCjcwUzYQFmNn6nSt+ u3zxt5GHiQFRhmOmcobNA== Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:14:51 -0000 On Nov 14, 2009, at 11:13 AM, Nelson B Bolyard wrote: > On 2009-11-13 08:46 PDT, Nicolas Williams wrote: >> >> The post with message-ID <20091113005419.GQ1105@Sun.COM>, subject >> "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600 >> yesterday most certainly described no Hello extensions, only a >> Finished >> message verify_data computation change. > > EKR and Marsh Ray and some others will recall that I proposed > essentially > the same proposal that Nico is now proposing in the meeting meeting in > Mountain View on September 29, 2009 to which Marsh Ray invited EKR, > myself > and numerous others from this working group. > > I proposed that a change in the computation of the TLS Finished > message > to include some value derived from the master secret previously in > use on > the connection before the current renegotiation (such as the Finished > message contents or some other value "extracted" from the master > secret) > would avoid the overhead of the new extensions on the wire. My goal > was > to avoid the extra bandwidth and memory cost of those extensions, > which > might be deemed too costly in certain low memory or bandwidth > constrained > applications. > > Others in the meeting responded that changing the definition of the > computation of the Finished messages was a change to the base protocol > specification (which adding an extension is not), and thus the change > I proposed would make TLS become (say) TLS 1.3. In that proposal, would there have been any explicit indicator sent by the client and server to indicate that they intend to use the the modified Finished message? One way to avoid most of the overhead from the current ID would be to keep the extension *always* empty. If the client and server both send it during any given handshake, then the Finished messages concluding that handshake will be computed mostly in the standard way, but if it's a renegotiation handshake, including the previous handshake's Finished messages in the handshake_messages that will be hashed. [Open question: Where should they go? Maybe the easiest is to always hash them at the end; client first, server second.] This has the same security properties as draft-rescorla-tls- renegotiation-00.txt, but saves 40 plaintext bytes (or 28 over the obvious variant of that ID where you remove the non-functional overhead, i.e. the server's copy of the client's verify_data.) The step up to TLS 1.3 will be easy: Just make the modified Finished computation the default for the new protocol (i.e., no longer requiring the extension-based negotiation). Bodo From Nicolas.Williams@sun.com Sun Nov 15 11:26:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850C83A68B4 for ; Sun, 15 Nov 2009 11:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 Nn2+JESHoRWF for ; Sun, 15 Nov 2009 11:26:46 -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 BD18D3A67B4 for ; Sun, 15 Nov 2009 11:26:46 -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 nAFJQcIj004322 for ; Sun, 15 Nov 2009 19:26:46 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 nAFJQbuE055894 for ; Sun, 15 Nov 2009 12:26:37 -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 nAFJ7UUg021060; Sun, 15 Nov 2009 13:07:30 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAFJ7SAB021059; Sun, 15 Nov 2009 13:07:28 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 15 Nov 2009 13:07:28 -0600 From: Nicolas Williams To: "Joseph Salowey (jsalowey)" Message-ID: <20091115190728.GU1105@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:26:47 -0000 On Sun, Nov 15, 2009 at 03:13:01AM -0800, Joseph Salowey (jsalowey) wrote: > E. The RI proposal has an issue if the client is patched and the server > does not implement the SSL 3.0 and the TLS 1.x specs correctly and the > client as a lenient policy which allows connection to insecure servers. > In this case the client would have to implement some fallback logic > (reconnect without extensions) to deal with broken servers. This logic > is well-known, but it leaves a roll-back attack open. This can be > plugged by using the proposed ciphersuite signal only in the case where > extensions cause a handshake or connection failure. The fallback > cipher-suite signaling for RI to prevent rollback extends TLS in an > unexpected way, but this is limited only to the case where we have to > deal with broken implementations. No, I don't think so. The RI proposal is fine in all respects, except that if there are old servers that are broken w.r.t. extensions and which could get patched to implement a simple fix, then RI is possibly too complex. Or at least that's what I think Martin is arguing. I'm not sure that's the case either. I think the RI is fine, but if it's not (see above) then we need _data_, meaning: names of implementations and implementors that are committed to fixing such old SW and who prefer a non-extension-based solution. > The ciphersuite-changes-handshake proposal has similar properties except Which proposal is that?? I proposed a fix that changes only the Finished message verify_data computations. > I think it comes down to whether we want to extend TLS in a standard way > for compliant implementations with a non-standard fallback behavior for > handling non-compliant implementations or extend TLS in a non-standard > way for all implementations. The standard vs. non-standard is somewhat > nonsensical because we can make something standard with IETF consensus, > however this will have implications on implementations and future > extensions moving forward. I agree. I dislike the argument that Hello extensions, being the blessed extensibility facility of TLS, is what must be used, but that alone is not enough to ditch EKR's proposal! > IMO, given that the two approaches are functionally equivalent I would > prefer to extend things in the standard way. EKR's proposal is being interop tested as we speak. That gives it a head start. IMO I think we'll end up with that. IMO folks who really want an alternative will have to come up with data (see above). Nico -- From bmoeller@acm.org Sun Nov 15 11:29:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274083A67B4 for ; Sun, 15 Nov 2009 11:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.974 X-Spam-Level: X-Spam-Status: No, score=-99.974 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 JOKou0KTIv7u for ; Sun, 15 Nov 2009 11:29:05 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 1DD1A3A6896 for ; Sun, 15 Nov 2009 11:29:05 -0800 (PST) Received: from [192.168.1.3] (c-76-102-12-92.hsd1.ca.comcast.net [76.102.12.92]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Mewwv-1NY9Nl0RC5-00OEiw; Sun, 15 Nov 2009 20:29:01 +0100 From: Bodo Moeller To: Nicolas Williams In-Reply-To: <20091114083136.GE1105@Sun.COM> References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <20091114083136.GE1105@Sun.COM> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 11:28:57 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX18ewZrieosyIfbhKm+q2FBilrAftpNS2yRor5z W16sOb8ygBFJpFSdwSGVEqKX7dsqn0PAPG+lIBXzJgpCKcTw0z GpMK9FiYgq16UNNuW/Y2w== Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:29:06 -0000 On Nov 14, 2009, at 12:31 AM, Nicolas Williams wrote: > On Sat, Nov 14, 2009 at 02:20:56AM +0000, David-Sarah Hopwood wrote: >> Nicolas Williams wrote: >>> Comments: >>> >>> 1) The rest of this comment can be ignored if the use of protocol >>> extensions in draft-rescorla-tls-renegotiate is deemed to not be a >>> problem. >>> >>> [...] >> >> The problem is that this unnecessarily breaks cases in which the >> possibility of attack couldn't have been prevented (because only >> one of the client and server supports the extension), and in which >> there may actually be no attack. > > That's a feature: for how do you know that "there may actually be no > attack"?? In general, you don't -- but sometimes you don't care. TLS is often used for opportunistic encryption (such as between SMTP servers that in many cases have no way to verify each other's certificate): If the client and server can encrypt, they'll do it to get protection at least against passive attackers; otherwise, they'll just fall back to unencrypted transmission. It would be a shame to have protocol negotiation problems make them fall back to unencrypted mode, when the currently deployed protocols could give them the security they expect. Bodo From marsh@extendedsubset.com Sun Nov 15 11:30:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101C43A68FF for ; Sun, 15 Nov 2009 11:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELHr6w1poRrW for ; Sun, 15 Nov 2009 11:30:47 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id D8FFE3A698A for ; Sun, 15 Nov 2009 11:30:46 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9ko9-000NDO-Uv for tls@ietf.org; Sun, 15 Nov 2009 19:30:46 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F40B1667C for ; Sun, 15 Nov 2009 19:30:42 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18swH8XbhkYMOpx6Q80VYznB1VR8Uin7YU= Message-ID: <4B0056E0.1000804@extendedsubset.com> Date: Sun, 15 Nov 2009 13:30:40 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911120512.nAC5CiIu019763@fs4113.wdf.sap.corp><82B3FF62-B9AE-45D0-AB6A-62ACACFC3F97@acm.org> <4B004A24.9080508@extendedsubset.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:30:48 -0000 Joseph Salowey (jsalowey) wrote: > > [Joe] The server is not allowed to send an extension if the client does > not send it. I don't see a spec problem here. I certainly see the logic in that. This is a very interesting point. The SSLv3 spec says Client Hello can contain extra data. In theory, we should be able to add client hello extensions and servers which don't interpret them will ignore them. Servers which do interpret them may respond with a Server Hello extension which is undefined by this spec, but that's OK because it doesn't happen unless the client asked for it. But there was no structure defined for that extra data and there were no major implementations to put anything there. Even if a client did want to use it, there was no type-length-value layout defined for it, so there was no way to send more than one extension. This effectively shut off that facility for experimental or vendor-specific use. The only party who could safely put any data there was the IETF, and that didn't seem to happen until RFC 3546 TLS Extensions (June 2003), which defined five specific extensions (and only for TLS 1.0 not SSLv3). Until then, there was no client implementation that sent extensions, and it was not possible for implementors to add their own in an interoperable way. Probably new development on SSLv3 had all but stopped by then. This effectively meant that server implementations were not tested to ignore extensions (or process them) until quite recently. So in practice, in order for a protocol structure to be usable in the future there has to have been some way to develop and test against it from the beginning. - Marsh From mrex@sap.com Sun Nov 15 11:31:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC743A69A4 for ; Sun, 15 Nov 2009 11:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 dLnwQppAWvLI for ; Sun, 15 Nov 2009 11:31:56 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3A5B53A67B4 for ; Sun, 15 Nov 2009 11:31:56 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAFJVq9r021346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 20:31:52 +0100 (MET) From: Martin Rex Message-Id: <200911151931.nAFJVpK3016250@fs4113.wdf.sap.corp> To: bmoeller@acm.org (Bodo Moeller) Date: Sun, 15 Nov 2009 20:31:51 +0100 (MET) In-Reply-To: <3EFE80FB-AB07-4BB3-ABDD-E836D27B7E54@acm.org> from "Bodo Moeller" at Nov 15, 9 11:13:46 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:31:57 -0000 Bodo Moeller wrote: > > One way to avoid most of the overhead from the current ID would be to > keep the extension *always* empty. If the client and server both send > it during any given handshake, then the Finished messages concluding > that handshake will be computed mostly in the standard way, but if > it's a renegotiation handshake, including the previous handshake's > Finished messages in the handshake_messages that will be hashed. > [Open question: Where should they go? Maybe the easiest is to always > hash them at the end; client first, server second.] My suggestion: always after ServerHello. At that point, servers and clients know whether they need to fallback to the old behaviour or not, provided that their policy/configuration should allow that. They should definitely go before the CertificateVerify message, so that the signature with the client certificate is also securely cryptographically bound to the channel (I don't like the idea to have the CertificateVerify succeed on a MITM attack and only the finished mac fail, if we can easily make both fail. > > The step up to TLS 1.3 will be easy: Just make the modified Finished > computation the default for the new protocol (i.e., no longer > requiring the extension-based negotiation). Correct! There really is no need to keep the old, unprotected negotiation around in TLS v1.3. If TLSv1.3 is proposed by the client and agreed to by the server, no additional signaling is necessary anymore. This is why adding the verify_data to the handshake messages hashes (my suggestion, always after ServerHello) -Martin From bmoeller@acm.org Sun Nov 15 11:36:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CD73A69DC for ; Sun, 15 Nov 2009 11:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 JthS74QPvYvU for ; Sun, 15 Nov 2009 11:36:16 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by core3.amsl.com (Postfix) with ESMTP id 682983A68FF for ; Sun, 15 Nov 2009 11:36:16 -0800 (PST) Received: from [192.168.1.3] (c-76-102-12-92.hsd1.ca.comcast.net [76.102.12.92]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MM2YK-1NHQvt2eIm-0089Xc; Sun, 15 Nov 2009 20:36:11 +0100 From: Bodo Moeller To: Eric Rescorla In-Reply-To: <20091113060004.55DC569F31E@kilo.networkresonance.com> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> Message-Id: <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 11:36:07 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX18MY6+Fs3IB29uNdJpZEH1hcdScZaXKeM1pUAu DE+zEnQFru74HwS5x9YahorFep8w82JQYuZjHGmVUe9bDNTXOn Wh0WimTFthcDtwoWn+W1w== Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:36:17 -0000 On Nov 12, 2009, at 10:00 PM, Eric Rescorla wrote: > > The issue isn't whether the client sends it. Of course the client > sends it. It's whether the client aborts the connection of the server > doesn't return it. Why make a client send it on the initial handshake if that client wouldn't have plans to abort the connection if the server doesn't acknowledge it? Interoperability seems easier if you don't send it. Bodo From bmoeller@acm.org Sun Nov 15 11:53:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563CB3A680D for ; Sun, 15 Nov 2009 11:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.959 X-Spam-Level: X-Spam-Status: No, score=-99.959 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_40=-0.185, HELO_EQ_DE=0.35, 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 p2tNq5p17ucw for ; Sun, 15 Nov 2009 11:53:49 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 93FAB3A67FF for ; Sun, 15 Nov 2009 11:53:34 -0800 (PST) Received: from [192.168.1.3] (c-76-102-12-92.hsd1.ca.comcast.net [76.102.12.92]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Ls5Ln-1ODZgJ02SV-013lYs; Sun, 15 Nov 2009 20:53:17 +0100 From: Bodo Moeller To: mrex@sap.com In-Reply-To: <200911151931.nAFJVpK3016250@fs4113.wdf.sap.corp> References: <200911151931.nAFJVpK3016250@fs4113.wdf.sap.corp> Message-Id: <23C64282-8C42-45AA-A730-4E5376D55EA9@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 11:53:13 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX19JHXkwmJOUIo9PSKooiu6LM70PK3bkyl7aG4v 6ZDTTpfANKWFBtU2n0IIWmpk8Miua6A9Qtx8xtu3A12eNJ+ZR7 ZmszK2FcSUOO4HZXC87Ew== Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:53:50 -0000 On Nov 15, 2009, at 11:31 AM, Martin Rex wrote: > Bodo Moeller wrote: >> One way to avoid most of the overhead from the current ID would be to >> keep the extension *always* empty. If the client and server both >> send >> it during any given handshake, then the Finished messages concluding >> that handshake will be computed mostly in the standard way, but if >> it's a renegotiation handshake, including the previous handshake's >> Finished messages in the handshake_messages that will be hashed. >> [Open question: Where should they go? Maybe the easiest is to always >> hash them at the end; client first, server second.] > > My suggestion: always after ServerHello. At that point, servers > and clients know whether they need to fallback to the old behaviour > or not, provided that their policy/configuration should allow that. > > They should definitely go before the CertificateVerify message, so > that > the signature with the client certificate is also securely > cryptographically bound to the channel (I don't like the idea to > have the CertificateVerify succeed on a MITM attack and only the > finished > mac fail, if we can easily make both fail. That's a very good point! So we'd actually be changing the handshake_message definition not just for purposes of the Finished messages, but also for purposes of the CertificateVerify message. We'd always pretend that the previous Finished messages occur in the present handshake after both Hello messages are done. [Do you agree with "client Finished first, server Finished second"? This is the obvious order if the previous handshake was a full handshake -- in case if was an abbreviated handshake (i.e., resuming a session), however, these messages would actually have been exchanged in the opposite order. *Not* following the original order in this case seems easier.] >> The step up to TLS 1.3 will be easy: Just make the modified Finished >> computation the default for the new protocol (i.e., no longer >> requiring the extension-based negotiation). > > Correct! There really is no need to keep the old, unprotected > negotiation around in TLS v1.3. If TLSv1.3 is proposed by the client > and agreed to by the server, no additional signaling is necessary > anymore. This is why adding the verify_data to the handshake messages > hashes (my suggestion, always after ServerHello) By the way, it would even be possible to specify more signals that could be used to switch to this modified handshake_message (and thus, Finished.verify_data) specification. If we assume that the extension is one way to enable this behavior, and the protocol version will be a second way, a magic ciphersuite number that new servers are expected to look out for could be a third option. Bodo From bmoeller@acm.org Sun Nov 15 11:58:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F192C3A6765 for ; Sun, 15 Nov 2009 11:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.848 X-Spam-Level: X-Spam-Status: No, score=-99.848 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 SlMjv6J8Mxv4 for ; Sun, 15 Nov 2009 11:58:26 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 04F573A635F for ; Sun, 15 Nov 2009 11:58:23 -0800 (PST) Received: from [192.168.1.3] (c-76-102-12-92.hsd1.ca.comcast.net [76.102.12.92]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MSVhA-1NbDiv48pA-00S18z; Sun, 15 Nov 2009 20:58:20 +0100 From: Bodo Moeller To: Eric Rescorla In-Reply-To: <20091113231013.8676669F516@kilo.networkresonance.com> References: <4AFC5D80.2030101@pobox.com> <4AFD91D1.7030409@pobox.com> <4AFDB8DF.4010608@pobox.com> <20091113231013.8676669F516@kilo.networkresonance.com> Message-Id: <54186B27-2E2C-4DCD-B8C5-7239FBABB631@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 11:58:15 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+hQU55dOz1WObxB9CRH2CAx+4Z65VtxB1e5hw m2qaivz3bxD4J5MlMpfWGFe73Q4kM88q0bj/4qfiZf9qRlsgOS DztoyEfg2SlelX1911BqQ== Cc: tls@ietf.org Subject: Re: [TLS] Two Opaque Values in Renegotiation_Info (was Re: webex) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 19:58:27 -0000 On Nov 13, 2009, at 3:10 PM, Eric Rescorla wrote: > At Fri, 13 Nov 2009 11:51:59 -0800, > Michael D'Errico wrote: >> I noticed in the logs that there was discussion of wanting to >> have two separate opaque values, I assume one for the client >> verify data and the other for the server verify data. > As far as I know this is not being actively considered. There's no point in having these two values sent in the same message. Using two fields would break backwards compatibility with draft- rescorla-tls-renegotiation-00.txt -- but backwards compatibility with this would be the only reason to keep the client's verify_data in the server's extension. Bodo From marsh@extendedsubset.com Sun Nov 15 12:02:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62693A6850 for ; Sun, 15 Nov 2009 12:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] 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 wDw6nn7q57cH for ; Sun, 15 Nov 2009 12:02:32 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id D67153A67D6 for ; Sun, 15 Nov 2009 12:02:32 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9lIu-0002gN-0b; Sun, 15 Nov 2009 20:02:32 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F2C18667C; Sun, 15 Nov 2009 20:02:30 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/9pb9pwSsZ23tudLdA18mEGXkRi4KuaIY= Message-ID: <4B005E54.6030600@extendedsubset.com> Date: Sun, 15 Nov 2009 14:02:28 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bodo Moeller , "tls >> \"tls@ietf.org\"" References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> In-Reply-To: <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:02:33 -0000 Bodo Moeller wrote: > > Why make a client send it on the initial handshake if that client > wouldn't have plans to abort the connection if the server doesn't > acknowledge it? Interoperability seems easier if you don't send it. Network monitoring, intrusion detection, firewall systems. It seems client and server aren't the only parties to the protocol anymore. - Marsh From Nicolas.Williams@sun.com Sun Nov 15 12:08:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2C03A680F for ; Sun, 15 Nov 2009 12:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[AWL=1.253, 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 gKPoLntojkBE for ; Sun, 15 Nov 2009 12:08:11 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 951F33A67D6 for ; Sun, 15 Nov 2009 12:08:10 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAFK89Mq024388 for ; Sun, 15 Nov 2009 20:08:09 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 nAFK88po018800 for ; Sun, 15 Nov 2009 13:08:08 -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 nAFJuY4h021074; Sun, 15 Nov 2009 13:56:34 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAFJuXvb021073; Sun, 15 Nov 2009 13:56:33 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 15 Nov 2009 13:56:33 -0600 From: Nicolas Williams To: "Michael D'Errico" Message-ID: <20091115195633.GV1105@Sun.COM> References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> <4AFF7EC3.8060805@pobox.com> <20091115173157.GR1105@Sun.COM> <4B004AE7.9000305@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B004AE7.9000305@pobox.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] A not-so crazy idea X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:08:11 -0000 On Sun, Nov 15, 2009 at 10:39:35AM -0800, Michael D'Errico wrote: > Nicolas Williams wrote: > >On Sat, Nov 14, 2009 at 08:08:35PM -0800, Michael D'Errico wrote: > >>Here's a crazy idea: we could define a completely incompatible change > >>to the way Finished messages are calculated even on initial handshakes. > > > >Not on initial. My proposal is to do it only on re-negotiate. > > Doing it on initial is necessary to protect clients when the server is > not patched. > > Remember that the attack happens on the client's INITIAL handshake! > We need to protect that handshake, and no other proposal does that > reliably. Simply finishing the initial handshake completes the attack. True. The server can always screw the client anyways, so the client has to trust server correctness, but, atleast in this case it'd be nice to have a critical indication in the initial handshake. That can be done with or without extensions, but if without extensions then clients will need to do the ugly fallback dance. Nico -- From mrex@sap.com Sun Nov 15 12:13:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390673A68B6 for ; Sun, 15 Nov 2009 12:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 tagged_above=-999 required=5 tests=[AWL=1.253, 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 pu95xJCoSdsa for ; Sun, 15 Nov 2009 12:13:36 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3DC1B3A6894 for ; Sun, 15 Nov 2009 12:13:36 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAFKDW4l020267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 21:13:32 +0100 (MET) From: Martin Rex Message-Id: <200911152013.nAFKDVkE018616@fs4113.wdf.sap.corp> To: bmoeller@acm.org (Bodo Moeller) Date: Sun, 15 Nov 2009 21:13:31 +0100 (MET) In-Reply-To: <23C64282-8C42-45AA-A730-4E5376D55EA9@acm.org> from "Bodo Moeller" at Nov 15, 9 11:53:13 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:13:37 -0000 Bodo Moeller wrote: > > So we'd actually be changing the handshake_message definition not just > for purposes of the Finished messages, but also for purposes of the > CertificateVerify message. We'd always pretend that the previous > Finished messages occur in the present handshake after both Hello > messages are done. > > [Do you agree with "client Finished first, server Finished second"? Yes. See my proposal in the first message of the thread "Protected Renegotiation -- refined proposal" > > > Correct! There really is no need to keep the old, unprotected > > negotiation around in TLS v1.3. If TLSv1.3 is proposed by the client > > and agreed to by the server, no additional signaling is necessary > > anymore. This is why adding the verify_data to the handshake messages > > hashes (my suggestion, always after ServerHello) > > By the way, it would even be possible to specify more signals that > could be used to switch to this modified handshake_message (and thus, > Finished.verify_data) specification. If we assume that the extension > is one way to enable this behavior, and the protocol version will be a > second way, a magic ciphersuite number that new servers are expected > to look out for could be a third option. I would strongly recommend against several different methods of signaling. It will be more work for implementors, more to interop-test more to get wrong. Just one signal for existing protocol specs SSLv3 -> TLSv1.2 is perfectly sufficient. Implied new behaviour with TLSv1.3 is fine. -Martin From bmoeller@acm.org Sun Nov 15 12:16:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787133A6816 for ; Sun, 15 Nov 2009 12:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, 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 HosF292ocXEw for ; Sun, 15 Nov 2009 12:16:57 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by core3.amsl.com (Postfix) with ESMTP id 7AB783A680E for ; Sun, 15 Nov 2009 12:16:57 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LckOB-1NtnNd1eT9-00jlSP; Sun, 15 Nov 2009 21:16:51 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4B005E54.6030600@extendedsubset.com> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> <4B005E54.6030600@extendedsubset.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 12:16:47 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX199uf9zk57NaEu/pntqFpwgOYicQ1cupZkI0KO j8ZClGQ1HpvdHXkfG9p7Sl+DQqFWWiC0zMYoPs0KCF8haqYo4j jh6Z2sPVBrgsnPdtCIgcg== Cc: "tls >> \"tls@ietf.org\"" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:16:58 -0000 On Nov 15, 2009, at 12:02 PM, Marsh Ray wrote: > Bodo Moeller wrote: >> Why make a client send it on the initial handshake if that client >> wouldn't have plans to abort the connection if the server doesn't >> acknowledge it? Interoperability seems easier if you don't send it. > > Network monitoring, intrusion detection, firewall systems. > > It seems client and server aren't the only parties to the protocol > anymore. I've seen this line of argument in the discussion before. However, I don't think it strongly suggests a particular answer to this question: Arguably I'd rather have monitoring tell me about clients that will *tolerate* a handshake with a server that doesn't support the extension (not so much about clients that don't support the extension at all). In that case, I wouldn't want these clients to send the extension on the initial handshake. Bodo From marsh@extendedsubset.com Sun Nov 15 12:22:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BAD3A6827 for ; Sun, 15 Nov 2009 12:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=1.177, 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 HXSCKqNhfipS for ; Sun, 15 Nov 2009 12:22:38 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id D9C013A68FD for ; Sun, 15 Nov 2009 12:22:06 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9lbq-0008tW-0J for tls@ietf.org; Sun, 15 Nov 2009 20:22:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E17AC667C for ; Sun, 15 Nov 2009 20:22:04 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Z1K44YMQQ0tI47HkAPQCXhXqZGV7Uf4A= Message-ID: <4B0062EA.8060906@extendedsubset.com> Date: Sun, 15 Nov 2009 14:22:02 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> <4B005E54.6030600@extendedsubset.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:22:39 -0000 Bodo Moeller wrote: > > Arguably I'd rather have monitoring tell me about clients that will > *tolerate* a handshake with a server that doesn't support the extension > (not so much about clients that don't support the extension at all). In > that case, I wouldn't want these clients to send the extension on the > initial handshake. Good point. These systems will probably spot unsafe renegotiations happening. It may be that we need two bits: 'endpoint patched' and 'endpoint configured secure'. - Marsh From bmoeller@acm.org Sun Nov 15 12:30:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28AE3A6816 for ; Sun, 15 Nov 2009 12:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.575 X-Spam-Level: X-Spam-Status: No, score=-100.575 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HELO_EQ_DE=0.35, 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 1jTeVo7rosyT for ; Sun, 15 Nov 2009 12:30:54 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by core3.amsl.com (Postfix) with ESMTP id C26F43A6849 for ; Sun, 15 Nov 2009 12:30:53 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MWvfk-1NfZnR0Yzc-00W5gf; Sun, 15 Nov 2009 21:30:50 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4B0062EA.8060906@extendedsubset.com> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> <4B005E54.6030600@extendedsubset.com> <4B0062EA.8060906@extendedsubset.com> Message-Id: <1F698852-2C4B-4F21-8B4F-0D6CFA6BB41E@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 12:30:46 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX19uUw4G+C1R27j6fINXJOOvk2c1AdI6zdpUZbw yvVEZIjGIb5IT1sq32+W5gOQyeSlUjP6DFn+iVO7PSFqtSrXwg HmGYWQEEqwzOAWp0abnOA== Cc: "tls@ietf.org" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:30:54 -0000 On Nov 15, 2009, at 12:22 PM, Marsh Ray wrote: > Bodo Moeller wrote: >> >> Arguably I'd rather have monitoring tell me about clients that will >> *tolerate* a handshake with a server that doesn't support the >> extension >> (not so much about clients that don't support the extension at >> all). In >> that case, I wouldn't want these clients to send the extension on the >> initial handshake. > > Good point. > > These systems will probably spot unsafe renegotiations happening. How would they do that? Everything is supposed to be encrypted then. > It may be that we need two bits: 'endpoint patched' and 'endpoint > configured secure'. I don't think the protocol should too much be designed around making monitoring systems happy. You can't do this for all interesting issues that client or server implementations might have anyway. Here we have a vulnerability that's easy to fix in such a way that monitoring systems can see some fix deployment information, so why not. Adding extra flags just for monitoring's sake, I'm not so sure. Bodo From nelson@bolyard.me Sun Nov 15 12:34:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570863A6861 for ; Sun, 15 Nov 2009 12:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9riIj5JHiB2o for ; Sun, 15 Nov 2009 12:34:05 -0800 (PST) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id 7AAC33A67B0 for ; Sun, 15 Nov 2009 12:34:05 -0800 (PST) Received: (qmail 26132 invoked from network); 15 Nov 2009 20:34:04 -0000 Received: from unknown (24.5.142.42) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 15 Nov 2009 20:34:04 -0000 Message-ID: <4B00662E.1020506@bolyard.me> Date: Sun, 15 Nov 2009 12:35:58 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: "tls@ietf.org" References: <4AFF79A4.6020706@extendedsubset.com> In-Reply-To: <4AFF79A4.6020706@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:34:06 -0000 On 2009-11-14 19:46 PDT, Marsh Ray wrote: > The current draft-rescorla-tls-renegotiation represents a good solution, > at least from the theoretical perspective. However, when one begins to > consider the practical difficulties it is encountering in actual > deployment it becomes clear that it is not likely to be a good solution > in practice. It is for this reason that we need to look at other > proposals with the aim of providing the most compatible and easiest to > implement fix on existing systems. > > This means: > > === R5. Not using an extension to implement the fix. > > Currently there are no examples of extensions used in a critical role > between interoperable systems, even where there would be significant > gain (financial and otherwise) from their use (e.g., SNI). An urgent > security-critical bug fix is absolutely not the place for blazing new > trails. > > It appears that somewhere between 20% and 40% of current SSL/TLS traffic > is between systems that either preferred not to (or could not) use TLS > 1.0 with extensions. The same logic kept some browsers from disabling SSLv2 for years. When SSLv2 was finally dropped, there were numerous complaints received from corporate types complaining that the action had been "premature". There will ALWAYS be companies who procrastinate as long as possible on any software upgrades. Let's not let them dictate how we fix TLS. Let's do the right thing here, even if it means forcing some to upgrade. > === R6. The fix must work for SSLv3. What does that mean? - Does it mean devising a "fix" for SSLv3 that allows patched but still SSLv3-only clients to safely renegotiate with patched but still SSLv3-only servers? - Does it mean devising a way for patched but still SSLv3-only clients to detect that they are connecting to unpatched and vulnerable SSLv3 only servers, and refuse to connect with them, on the grounds that doing so may be seen by that server as a completion of a renegotiation? > One source measured 22% of current SSL/TLS traffic still over SSLv3, and > other sources of data have tended to confirm that. This is far too large > a group to ignore, or expect to "just upgrade". That's what they said about SSL2. > Even software that does support newer versions of the protocol will > often fall back to SSLv3 at the first sign of trouble. Any fix which > does not address SSLv3 can simply be bypassed by the attacker I think you're assuming that the browsers will decide that continued interoperability with the old vulnerable servers is more desirable that being able to claim that their browsers are invulnerable to this attack. I tend to assume the opposite. I believe that one of the reasons that browsers (at least one browser) have been willing to "fall back" has been the perception that TLS 1.0 did not offer significantly (or perhaps, ANY) greater security than SSL 3.0), and so falling back from TLS 1.0 to SSL 3.0 was not perceived as a loss of security. Now, that perception may be changing (may have already changed), a LOT. If so, it may be that the time for the fall back is hastily ending. Let's not assume that it isn't. > === R7. The fix must be easy to merge across existing code branches. Sorry, that presumes reasonable development practices have been followed in the creation of those branches. I think this is at best a highly desirable thing, not a requirement. > === R9. Must interoperate perfectly with unpatched systems. Again, what does that mean? Does it mean that a patched client connects without hesitation to an unpatched and vulnerable server, thereby falling victim to the attack? From Yair.Elharrar@audiocodes.com Sun Nov 15 12:35:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E513A688A for ; Sun, 15 Nov 2009 12:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_ILLEGAL_IP=1.908] 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 MEmysUupBdKl for ; Sun, 15 Nov 2009 12:35:22 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id 0ADC63A6861 for ; Sun, 15 Nov 2009 12:35:21 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.0.13]) by incoming.audiocodes.com with ESMTP; 15 Nov 2009 22:11:51 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80:0000:0000:0000:00d9:1fca:234.186.136.40]) by aclcas.corp.audiocodes.com ([10.1.0.13]) with mapi; Sun, 15 Nov 2009 22:35:58 +0200 From: Yair Elharrar To: "tls@ietf.org" Date: Sun, 15 Nov 2009 22:35:57 +0200 Thread-Topic: [TLS] A not-so crazy idea Thread-Index: AcpmL3U++M43uu82REK8bKXhB/TsdQAAVxpT Message-ID: References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> <4AFF7EC3.8060805@pobox.com> <20091115173157.GR1105@Sun.COM> <4B004AE7.9000305@pobox.com>,<20091115195633.GV1105@Sun.COM> In-Reply-To: <20091115195633.GV1105@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] A not-so crazy idea X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:35:23 -0000 What if we just change the definition of the server's FINISHED message a bi= t; instead of sending Hash(handshake_msgs) to the client, the server will send Hash(handshake_msgs || verify_data) using the session's previous verify_data. There's no change to initial handshakes, of course, as there's no previous = verify_data. This means: 1. Patched client and patched server: renegotiation is safe. 2. Patched client, unpatched server: the client can calculate Hash(handshak= e_msgs) and tell that the server is unpatched. It is up to the client to de= cide whether to abort the session or not. 3. Unpatched client, patched server: renegotiation will fail, as it should. Yair -- This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message From marsh@extendedsubset.com Sun Nov 15 12:38:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B949F3A6861 for ; Sun, 15 Nov 2009 12:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.972 X-Spam-Level: X-Spam-Status: No, score=-0.972 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_05=-1.11] 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 blumFm-taNcK for ; Sun, 15 Nov 2009 12:38:39 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 153463A6812 for ; Sun, 15 Nov 2009 12:38:39 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9lrq-0008VU-6m; Sun, 15 Nov 2009 20:38:38 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C341E667C; Sun, 15 Nov 2009 20:38:35 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+QMxk7As0b+3HNlD4YKtohSeHQpOPrL8U= Message-ID: <4B0066C9.9090901@extendedsubset.com> Date: Sun, 15 Nov 2009 14:38:33 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bodo Moeller References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> <4B005E54.6030600@extendedsubset.com> <4B0062EA.8060906@extendedsubset.com> <1F698852-2C4B-4F21-8B4F-0D6CFA6BB41E@acm.org> In-Reply-To: <1F698852-2C4B-4F21-8B4F-0D6CFA6BB41E@acm.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:38:39 -0000 Bodo Moeller wrote: > > How would they do that? Everything is supposed to be encrypted then. They will notice handshake messages after the initial handshake. The record content type field is never encrypted. > I don't think the protocol should too much be designed around making > monitoring systems happy. You can't do this for all interesting issues > that client or server implementations might have anyway. Here we have a > vulnerability that's easy to fix in such a way that monitoring systems > can see some fix deployment information, so why not. Adding extra flags > just for monitoring's sake, I'm not so sure. Many, many sites will configure their stateful firewalls to shoot down any potentially-unsafe renegotiations. Without plaintext indicators, that will mean all renegotiations. - Marsh From mrex@sap.com Sun Nov 15 12:43:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2803A68BD for ; Sun, 15 Nov 2009 12:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.413 X-Spam-Level: X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=0.836, 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 viB1J+lcCv4W for ; Sun, 15 Nov 2009 12:43:14 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 944703A68B6 for ; Sun, 15 Nov 2009 12:43:14 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAFKhA5g020194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 21:43:10 +0100 (MET) From: Martin Rex Message-Id: <200911152043.nAFKhAbD020309@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Sun, 15 Nov 2009 21:43:10 +0100 (MET) In-Reply-To: <4B0062EA.8060906@extendedsubset.com> from "Marsh Ray" at Nov 15, 9 02:22:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:43:15 -0000 Marsh Ray wrote: > > Bodo Moeller wrote: > > > > Arguably I'd rather have monitoring tell me about clients that will > > *tolerate* a handshake with a server that doesn't support the extension > > (not so much about clients that don't support the extension at all). In > > that case, I wouldn't want these clients to send the extension on the > > initial handshake. > > Good point. > > These systems will probably spot unsafe renegotiations happening. > > It may be that we need two bits: 'endpoint patched' and 'endpoint > configured secure'. Do you really need more? If you see the client's signal in the ClientHello that it is updated and no signal for the new behaviour in the ServerHello, then you can distinguish configured secure (Client closes network connection with or without sending a fatal alert) from configured insecure (handshake continues). If your idea is about being able to "check" client's configuration on _any_ TLS connection, that is not something that TLS is designed (or supposed) to provide. -Martin From marsh@extendedsubset.com Sun Nov 15 12:56:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB553A69B5 for ; Sun, 15 Nov 2009 12:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_40=-0.185] 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 wTmWRhSVf8eq for ; Sun, 15 Nov 2009 12:56:07 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A08F13A6964 for ; Sun, 15 Nov 2009 12:56:07 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9m8k-000BZu-5q for tls@ietf.org; Sun, 15 Nov 2009 20:56:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 11256667C for ; Sun, 15 Nov 2009 20:56:03 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+2pUQnHIm366WBq1iDwPOfy2YEAXgsZRI= Message-ID: <4B006AE1.30206@extendedsubset.com> Date: Sun, 15 Nov 2009 14:56:01 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls >> \"tls@ietf.org\"" References: <4AFF79A4.6020706@extendedsubset.com> <4B00662E.1020506@bolyard.me> In-Reply-To: <4B00662E.1020506@bolyard.me> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:56:08 -0000 Nelson B Bolyard wrote: > On 2009-11-14 19:46 PDT, Marsh Ray wrote: >> >> === R5. Not using an extension to implement the fix. > > The same logic kept some browsers from disabling SSLv2 for years. > [...] Let's not let them dictate how we fix TLS. > Let's do the right thing here, even if it means forcing some to upgrade. I was with you on that 100% until a few days ago. In this case, there is no 'leverage' with which to push for a proper upgrade: approximately 99% of sites will just disable renegotiation entirely. >> === R6. The fix must work for SSLv3. > - Does it mean devising a "fix" for SSLv3 that allows patched but still > SSLv3-only clients to safely renegotiate with patched but still SSLv3-only > servers? Yes. > - Does it mean devising a way for patched but still SSLv3-only clients > to detect that they are connecting to unpatched and vulnerable SSLv3 only > servers, and refuse to connect with them, on the grounds that doing so > may be seen by that server as a completion of a renegotiation? Yes. > I think you're assuming that the browsers will decide that continued > interoperability with the old vulnerable servers is more desirable that > being able to claim that their browsers are invulnerable to this attack. Mainly that the fix has to be patchable at the TLS library level and can't require application code changes. >> === R7. The fix must be easy to merge across existing code branches. > > Sorry, that presumes reasonable development practices have been followed > in the creation of those branches. I think this is at best a highly > desirable thing, not a requirement. Yeah, it's not the kind of thing that makes a good functional requirement when designing a new system. However, the reality is that a fix that requires a serious porting effort is going to take longer to deploy than one that can be done with simpler code change and this needs to be taken into consideration when choosing between alternatives. >> === R9. Must interoperate perfectly with unpatched systems. > > Again, what does that mean? > Does it mean that a patched client connects without hesitation to an > unpatched and vulnerable server, thereby falling victim to the attack? It means that whatever fix we propose on to the public has to work seamlessly. My guess is that we have one shot at delivering something in a window that ends quite soon. If the patch makes a first impression at breaking one in ten connections, most admins will simply choose the patch which disables all renegotiation. Once that happens, it's gone for good, yet a lot of important systems depend on it. - Marsh From nelson@bolyard.me Sun Nov 15 13:04:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460AB3A6827 for ; Sun, 15 Nov 2009 13:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0uyDEYtdMJ5 for ; Sun, 15 Nov 2009 13:04:19 -0800 (PST) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by core3.amsl.com (Postfix) with SMTP id 66A943A66B4 for ; Sun, 15 Nov 2009 13:04:19 -0800 (PST) Received: (qmail 15964 invoked from network); 15 Nov 2009 21:04:13 -0000 Received: from unknown (24.5.142.42) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 15 Nov 2009 21:04:13 -0000 Message-ID: <4B006D46.6070107@bolyard.me> Date: Sun, 15 Nov 2009 13:06:14 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: "tls@ietf.org" References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> In-Reply-To: <20091115111834.334A869F79B@kilo.networkresonance.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:04:20 -0000 On 2009-11-15 03:18 PDT, Eric Rescorla wrote: > 1. Servers which do not wish to do renegotiation can protect themselves > without any change to the TLS protocol or to the client. I think > it's pretty clearly desirable to have such servers continue to > work with downrev clients. Agreed. > 2. Any fix must cause renegotiation between upgraded and unupgraded > agents to fail. Ummm, remembering that a client's initial handshake may be a server's renegotiation, I think that requirement needs to say that Any fix must cause any handshake between upgraded and non-upgraded agents to fail, when that handshake is seen as a renegotiation by the server, whether it is seen as an initial handshake or as a renegotiation by the client. > This is true whether the fix is explicitly signalled > via an extension, explicitly signalled via a cipher suite/version, > or unsignaled, such as by extending the finished message hash to > incorporate earlier handshakes/incorporating previous finished > messages into the PRF. > > Thus, the minimal change is not to change initial negotiations at > all but simply to change renegotiations. This is quite possible > with RI simply by not sending it on the initial negotiation. Of > course, sending it on renegotiation will cause interoperation > failure with vulnerable servers, but that's the desired outcome. Are there clients who really want to remain vulnerable? > 3. If we only make the minimal change, then clients will not be able > to determine whether they are connecting to a vulnerable server > even if they have no intention of renegotiating. I believe clients (browsers, in particular) will not be able to claim they are invulnerable, and will be accused of remaining vulnerable, as long as they are not able to make that determination. > I'm unconvinced that there are a significant number of > applications which: > > (1) Can't use TLS. > (2) Do renegotiation. > (3) Are going to upgrade their stacks to support some new > secure renegotiation thing change. > (4) Won't just upgrade to TLS. > > Certainly all the major stack vendors have had TLS support for a very > long time. For instance, you have to go back to before OpenSSL even > existed to find a version of SSLeay that is SSLv3 only. And if you do > support TLS, the effort of just implementing doing this extension is > really not significantly greater than the other proposed fixes. I agree. I don't hear any customers of my employer demanding a fix that avoids going to TLS. The customers either a) have been avoiding any and all updates entirely for a long time, or b) upgrade pretty regularly as "security updates" come out, and are already using TLS-capable stacks. If anything finally motivates those customers with the very old software to finally update their software, the only choices available to them will all include TLS-capable stacks. They will still have the option of enabling only SSL3, in which case renegotiation will be disabled. If they need renegotiation, they need only to enable TLS, and Voila. From marsh@extendedsubset.com Sun Nov 15 13:04:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DB03A692D for ; Sun, 15 Nov 2009 13:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.914, 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 2owHs0vsW0dK for ; Sun, 15 Nov 2009 13:04:44 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A879F3A68D9 for ; Sun, 15 Nov 2009 13:04:44 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9mH5-000D3h-QE; Sun, 15 Nov 2009 21:04:43 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C2607667C; Sun, 15 Nov 2009 21:04:41 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19RW21QVImiKbUEZ3jwDJReG9hUfu1EquY= Message-ID: <4B006CE7.9050804@extendedsubset.com> Date: Sun, 15 Nov 2009 15:04:39 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911152043.nAFKhAbD020309@fs4113.wdf.sap.corp> In-Reply-To: <200911152043.nAFKhAbD020309@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:04:45 -0000 Martin Rex wrote: > If you see the client's signal in the ClientHello that it is updated > and no signal for the new behaviour in the ServerHello, then you can > distinguish configured secure (Client closes network connection with > or without sending a fatal alert) from configured insecure (handshake > continues). Good point. The info may be available without the need to be stated explicitly. But only after an insecure handshake gets underway. > If your idea is about being able to "check" client's configuration on > _any_ TLS connection, that is not something that TLS is designed > (or supposed) to provide. We're dealing with something that's already outside of the original design, so we can't afford to be too principled. These protocol bits have to satisfy the installed base. Is it all that different than sending GMT instead of random data? - Marsh From ynir@checkpoint.com Sun Nov 15 13:07:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5893A684E for ; Sun, 15 Nov 2009 13:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 7GYvdwboTDRf for ; Sun, 15 Nov 2009 13:07:37 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 227D63A66B4 for ; Sun, 15 Nov 2009 13:07:37 -0800 (PST) X-CheckPoint: {4B006A45-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CE91E29C007; Sun, 15 Nov 2009 23:07:32 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id AB6F829C004; Sun, 15 Nov 2009 23:07:32 +0200 (IST) X-CheckPoint: {4B006A42-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAFL7VGo003165; Sun, 15 Nov 2009 23:07:32 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 15 Nov 2009 23:07:37 +0200 From: Yoav Nir To: Yair Elharrar , "tls@ietf.org" Date: Sun, 15 Nov 2009 23:04:38 +0200 Thread-Topic: [TLS] A not-so crazy idea Thread-Index: AcpmL3U++M43uu82REK8bKXhB/TsdQAAVxpTAAGbG48= Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EC05F@il-ex01.ad.checkpoint.com> References: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com> <4AFF77B1.1000106@jacaranda.org> <4AFF7EC3.8060805@pobox.com> <20091115173157.GR1105@Sun.COM> <4B004AE7.9000305@pobox.com>, <20091115195633.GV1105@Sun.COM>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] A not-so crazy idea X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:07:38 -0000 That would mean that RFC-compliant clients just don't work. A change like t= hat is fine for a future version, like 1.3, but changing the behavior of 1.= 0 in a non-compliant way is just wrong. You really have to signal it. Of course, once you have a new version like 1.3, you don't need both old an= d new behavior. There's jut the new, TLS 1.3 way of calculating the Finish= ed message. ________________________________________ From: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Yair Elharra= r [Yair.Elharrar@audiocodes.com] Sent: Sunday, November 15, 2009 22:35 To: tls@ietf.org Subject: Re: [TLS] A not-so crazy idea What if we just change the definition of the server's FINISHED message a bi= t; instead of sending Hash(handshake_msgs) to the client, the server will send Hash(handshake_msgs || verify_data) using the session's previous verify_data. There's no change to initial handshakes, of course, as there's no previous = verify_data. This means: 1. Patched client and patched server: renegotiation is safe. 2. Patched client, unpatched server: the client can calculate Hash(handshak= e_msgs) and tell that the server is unpatched. It is up to the client to de= cide whether to abort the session or not. 3. Unpatched client, patched server: renegotiation will fail, as it should. Yair -- From nelson@bolyard.me Sun Nov 15 13:12:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0EE73A6824 for ; Sun, 15 Nov 2009 13:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] 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 iDndUfmhFceN for ; Sun, 15 Nov 2009 13:12:31 -0800 (PST) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id 4D3213A67CC for ; Sun, 15 Nov 2009 13:12:31 -0800 (PST) Received: (qmail 7542 invoked from network); 15 Nov 2009 21:12:30 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 15 Nov 2009 21:12:30 -0000 Message-ID: <4B006F37.6030905@bolyard.me> Date: Sun, 15 Nov 2009 13:14:31 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> In-Reply-To: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:12:32 -0000 On 2009-11-15 03:38 PDT, Eric Rescorla wrote: > So, thinking further on my earlier message, I think the following > elaboration will work a bit better: > > - Strict clients (those which wish to insist on RI) generate RI on > initial handshake. As I said earlier, I don't think this is > useful, but it works. > > - Lenient clients do not generate RI on initial handshake but do > generate it on rehandshake with TLS 1.0+ only. > + Moderately lenient clients can fail if the server does not > do RI. > + Really lenient clients can ignore the server's failure to > do RI. Aren't your so-called Lenient clients still 100% vulnerable to the attack? What prevents their initial handshakes from being used by an attacker as renegotiations with a vulnerable server? From nelson@bolyard.me Sun Nov 15 13:21:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37653A6A06 for ; Sun, 15 Nov 2009 13:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=1.177, 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 hf2oVa40xlF6 for ; Sun, 15 Nov 2009 13:21:04 -0800 (PST) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id E6F343A6A02 for ; Sun, 15 Nov 2009 13:21:03 -0800 (PST) Received: (qmail 2930 invoked from network); 15 Nov 2009 21:21:03 -0000 Received: from unknown (24.5.142.42) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 15 Nov 2009 21:21:03 -0000 Message-ID: <4B007138.8060809@bolyard.me> Date: Sun, 15 Nov 2009 13:23:04 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:21:04 -0000 On 2009-11-15 03:13 PDT, Joseph Salowey (jsalowey) wrote: > We need to close on this issue. Agreed! > E. The RI proposal has an issue if the client is patched and the server > does not implement the SSL 3.0 and the TLS 1.x specs correctly and the > client as a lenient policy which allows connection to insecure servers. > In this case the client would have to implement some fallback logic > (reconnect without extensions) to deal with broken servers. This logic > is well-known, but it leaves a roll-back attack open. AFAIK, there is a small number of well known client products (browsers) that do this today. These products offer ("push") updates quite frequently. I think it is probable that these products will alter their fall-back logic in light of this vulnerability, so that it will not be a trivial way for attackers to bypass the fix for the vulnerability. > Situation E is one that we expect to get less common because we want all > implementations to get patched and clients may start requiring the fix > because this is the only way they can protect themselves. Agreed. From mrex@sap.com Sun Nov 15 13:30:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98643A6A10 for ; Sun, 15 Nov 2009 13:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_CODEINE=0.833] 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 glMIwjOUmkSz for ; Sun, 15 Nov 2009 13:30:50 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 6472C3A6A07 for ; Sun, 15 Nov 2009 13:30:50 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAFLUiXe013590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 22:30:45 +0100 (MET) From: Martin Rex Message-Id: <200911152130.nAFLUiIP022845@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Sun, 15 Nov 2009 22:30:44 +0100 (MET) In-Reply-To: <4B00662E.1020506@bolyard.me> from "Nelson B Bolyard" at Nov 15, 9 12:35:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:30:51 -0000 Nelson B Bolyard wrote: > > On 2009-11-14 19:46 PDT, Marsh Ray wrote: > > > > === R5. Not using an extension to implement the fix. > > > > Currently there are no examples of extensions used in a critical role > > between interoperable systems, even where there would be significant > > gain (financial and otherwise) from their use (e.g., SNI). An urgent > > security-critical bug fix is absolutely not the place for blazing new > > trails. > > > > It appears that somewhere between 20% and 40% of current SSL/TLS traffic > > is between systems that either preferred not to (or could not) use TLS > > 1.0 with extensions. > > The same logic kept some browsers from disabling SSLv2 for years. Flawed comparison. SSLv2 known security problems. SSLv3 does not. SSL renegotiation has a problem, but across the board from SSLv3 all the way to TLSv1.2. > > There will ALWAYS be companies who procrastinate as long as possible on > any software upgrades. Let's not let them dictate how we fix TLS. > Let's do the right thing here, even if it means forcing some to upgrade. That would be extremely poor engineering. We are perfectly able to provide a solution that can be applied to all protocol versions out there, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2. Designing the fix so that adding it to SSLv3 is much harder than for TLSv1.2 is irresponsible. > > > === R6. The fix must work for SSLv3. > > What does that mean? > > - Does it mean devising a "fix" for SSLv3 that allows patched but still > SSLv3-only clients to safely renegotiate with patched but still SSLv3-only > servers? It means that secure renegotiation should also be used when both peers negotiation protocol version 0x03.0x00. If the fix does not do that, then the fix is not a fix, but another failure. > > That's what they said about SSL2. > > > Even software that does support newer versions of the protocol will > > often fall back to SSLv3 at the first sign of trouble. Any fix which > > does not address SSLv3 can simply be bypassed by the attacker > > I think you're assuming that the browsers will decide that continued > interoperability with the old vulnerable servers is more desirable that > being able to claim that their browsers are invulnerable to this attack. > I tend to assume the opposite. This is ridiculous. Browser vendors added the fallback renegotiation not because they had too much time on their hands. They wanted to use TLS extension SNI or newer TLS versions and encountered severe interop issues. The TLS WG can easily devise a fix for secure TLS renegotiation that will work even during the fallback, and that can be hotfixed into the entire installed base immediately with an extremely low probability of breaking interoperability. I also would try to get a client-side fix to our customers in 2-3 weeks if it does NOT use extensions. (we don't support renegotiation on the server, so adding the signaling to the initial Handshake is all I have to do for the server). If the TLS WG ships the TLS extension RI, then it will be several months before I will be shipping anything for the client side, because I first will need to think about solutions for the interop problems that will arise and how to make the client-side behaviour configurable (which requires changes to all applications). An extension-less Client->Server Signaling on initial handshake is something that I would risk shipping immediately without a configuration option, taking care about interop problems when they're reported. > > Now, that perception may be changing (may have already changed), a LOT. Huh? What are you refering to? Those that moved to newer implementations and started to rely on renegotiation in their Website structure are now the ones who suffer the most. > > > === R7. The fix must be easy to merge across existing code branches. > > Sorry, that presumes reasonable development practices have been followed > in the creation of those branches. I think this is at best a highly > desirable thing, not a requirement. That is a pretty significant and realistic requirement. In particular, if you have several different code lines providing different protocol levels of TLS, then a fix where 90% of the code changes is the same for all code lines is much better than one that needs to be individually developed for every codeline. Therefore devising the fix so that is requires minimal changes for the oldest implementation affected by this protocol defect (SSLv3) is the most reasonable approach to fixing that defect. > > > === R9. Must interoperate perfectly with unpatched systems. > > Again, what does that mean? > Does it mean that a patched client connects without hesitation to an > unpatched and vulnerable server, thereby falling victim to the attack? It means that if the fix is designed in a fashion that it can be used by clients at all protocol levels, even SSLv3 immediately with an extremely low probability of breaking existing usage scenarios (and that DOES INCLUDE servers that are still unpatched), then we will see by far the quickest adoption of the update. -Martin From nelson@bolyard.me Sun Nov 15 13:45:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1980A3A68D0 for ; Sun, 15 Nov 2009 13:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 j2IJotHB8T3w for ; Sun, 15 Nov 2009 13:45:10 -0800 (PST) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id 637AD3A67BE for ; Sun, 15 Nov 2009 13:45:10 -0800 (PST) Received: (qmail 22486 invoked from network); 15 Nov 2009 21:45:09 -0000 Received: from unknown (24.5.142.42) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 15 Nov 2009 21:45:09 -0000 Message-ID: <4B0076DD.9000907@bolyard.me> Date: Sun, 15 Nov 2009 13:47:09 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 CC: "tls@ietf.org" References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com>, <4AFD850C.7010704@pobox.com> <006FEB08D9C6444AB014105C9AEB133FB36A4EC024@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EC024@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:45:11 -0000 On 2009-11-13 13:37 PDT, Yoav Nir wrote: > Actually, there have been messages suggesting that clients sending this > (or any other) extension, may have their session terminated, especially > if using SSLv3 and even with some TLS 1.0 servers. That is true. There definitely is some small fraction of SSL/TLS servers out there that will not complete a handshake if the client hello has any extensions whatsoever. > If that is true for even a small minority of servers (say, 1%) we can't > realistically expect browser vendors to add this, except buried deeply in > some advanced menu. By that logic, you might assume that browsers would not use extensions at all today, "except buried deeply in some advanced menu", but that is not the case at all. Browsers DO use extensions when attempting to negotiate TLS today, but not when attempting to negotiate SSL 3.0 (only). Some browsers have a "fall back" strategy that lets them try SSL 3.0 after a TLS handshake attempt fails. Whether that strategy will remain viable going forward remains to be seen. But don't expect use of TLS hello extensions to stop because of it. > I wish we had some hard data on this, but if this is true, we may need > to find other ways for the client to signal support, or to signal > re-negotiation. There is no objection among browsers to using this extension. /Nelson Bolyard Developer of TLS library used by Firefox From bmoeller@acm.org Sun Nov 15 13:48:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF903A6A0A for ; Sun, 15 Nov 2009 13:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.412 X-Spam-Level: X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 qOCxyqbjwYOY for ; Sun, 15 Nov 2009 13:48:34 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id B90893A67F4 for ; Sun, 15 Nov 2009 13:48:33 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MGmAP-1NND5S0Lmz-00DLQm; Sun, 15 Nov 2009 22:48:32 +0100 From: Bodo Moeller To: Nelson B Bolyard In-Reply-To: <4B006D46.6070107@bolyard.me> References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> <4B006D46.6070107@bolyard.me> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 13:48:28 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+ZBhIyyiVpiVEIrscjIMwby9Wi/o9O0fFaWr1 2Sct+US9fv+m73gEfP5IBtuYkmg3JuRjH1CwcpSPV15uCOnQDx E+ImNrdYJf7NhEgaiDbzQ== Cc: "tls@ietf.org" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:48:35 -0000 On Nov 15, 2009, at 1:06 PM, Nelson B Bolyard wrote: > On 2009-11-15 03:18 PDT, Eric Rescorla wrote: >> Thus, the minimal change is not to change initial negotiations at >> all but simply to change renegotiations. This is quite possible >> with RI simply by not sending it on the initial negotiation. Of >> course, sending it on renegotiation will cause interoperation >> failure with vulnerable servers, but that's the desired outcome. > Are there clients who really want to remain vulnerable? Um, strawman? The minimal change is helpful for clients that want to remain interoperable with servers that haven't been updated yet, because - some servers wouldn't really have to be updated because they don't support renegotiation in the first place; - atomically updating all clients and servers isn't possible; - the attack is irrelevant for opportunistic-encryption scenarios -- if these clients *accept*, as trade-off, that they'd also continue to be able to engage in insecure connections (when connecting to insecure servers). This doesn't mean that they *want* to be vulnerable. It doesn't even imply that they necessarily *are* vulnerable (this depends on what the higher protocol layers are actually doing with the TLS connections, and what servers they open connections to). Bodo From bmoeller@acm.org Sun Nov 15 14:04:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1B03A688D for ; Sun, 15 Nov 2009 14:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 hAmPs0iVB6ip for ; Sun, 15 Nov 2009 14:04:03 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id BB83C3A67F4 for ; Sun, 15 Nov 2009 14:04:02 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LuJFv-1OBLmk0kLP-011AQO; Sun, 15 Nov 2009 23:03:58 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4AFF79A4.6020706@extendedsubset.com> References: <4AFF79A4.6020706@extendedsubset.com> Message-Id: <67C27EB3-804A-4A5D-91C1-451FCD684D21@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 14:03:54 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX19TyPuUIjfv1r+H9+Zed7G3Vnk2aKurYCiAhaa V4WteuL/acPdDfAXSHpA/l3WMAQbvkyOQmhdN9VIv9AXwoIgRy FGGjb1+u6XXa01a/5yxVw== Cc: "tls@ietf.org" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:04:03 -0000 On Nov 14, 2009, at 7:46 PM, Marsh Ray wrote: > === R6. The fix must work for SSLv3. > > One source measured 22% of current SSL/TLS traffic still over SSLv3, > and > other sources of data have tended to confirm that. This is far too > large > a group to ignore, or expect to "just upgrade". > > Even software that does support newer versions of the protocol will > often fall back to SSLv3 at the first sign of trouble. Any fix which > does not address SSLv3 can simply be bypassed by the attacker I don't agree that the fix must fully work for SSL 3.0. A fix that simply disallows renegotiation for SSL 3.0 (while updating the renegotiation protocol for TLS 1.0 and later -- or also for the "SSL 3.0 with TLS extensions" hybrid) could not be bypassed by the attacker. Bodo From nelson@bolyard.me Sun Nov 15 14:15:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBBAE3A6A37 for ; Sun, 15 Nov 2009 14:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_05=-1.11] 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 2tBz8JN2mGhk for ; Sun, 15 Nov 2009 14:15:23 -0800 (PST) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id 23A883A6A35 for ; Sun, 15 Nov 2009 14:15:22 -0800 (PST) Received: (qmail 25731 invoked from network); 15 Nov 2009 22:15:21 -0000 Received: from unknown (24.5.142.42) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 15 Nov 2009 22:15:20 -0000 Message-ID: <4B007DF1.6080200@bolyard.me> Date: Sun, 15 Nov 2009 14:17:21 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: IETF TLS Working Group Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [TLS] Safe vulnerability probing of servers possible w/o extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:15:23 -0000 I believe that, if a client "knows" that a certain TLS or SSL 3.0 server does not perform renegotiation (has disabled renegotiation), then the client may safely initiate TLS/SSL3 handshakes with that server, without any new extensions or other protocol changes. This leads me to wonder if there is a way by which a client can "probe" a remote server to determine whether that server does or does not support renegotiation, without possibility of itself falling victim to this renegotiation attack in the process of that probing. Is there a "safe" way to probe a remote server? It seems to me that a client might safely conduct such a probe as follows: 1) Connect to the server via TCP. 2) Initiate and complete a TLS 1.0 (or SSL 3.0) handshake, with no session ID (no attempt to resume any previously established session), and with no client authentication, and with no hello extensions. 3) Do not send ANY application data. 4) When the handshake is complete, immediately initiate a second handshake also with no session ID, with no client authentication, with no application data, and with no hello extensions. 5) attempt to complete the renegotiation. Then disconnect. If the renegotiation completes, the server is known to be vulnerable. If it does not, then repeat the test, but in step 3, send a simple anonymous request (e.g. http GET / request) with no identification and authentication of any form (no cookies, no basic auth, etc.) Again, if the renegotiation completes, the server is known to be vulnerable. If it does not, then the probability that the server supports renegotiation has been established to be low. I think this is "safe", in that, even if an attacker is attempting to use this client's initial handshake in a renegotiation attack, the client does not provide any I&A information that could be used to authorize the attacker's transaction, or that the attacker could subsequently replay. Are there any big holes in this scheme? From bmoeller@acm.org Sun Nov 15 14:22:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7FC3A68FD for ; Sun, 15 Nov 2009 14:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.624 X-Spam-Level: X-Spam-Status: No, score=-100.624 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_40=-0.185, HELO_EQ_DE=0.35, 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 PtFli0kpNMrQ for ; Sun, 15 Nov 2009 14:22:49 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 174663A6781 for ; Sun, 15 Nov 2009 14:22:49 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lf0SV-1O0OBV0UDX-00qDlu; Sun, 15 Nov 2009 23:22:47 +0100 From: Bodo Moeller To: Nelson B Bolyard In-Reply-To: <4B006F37.6030905@bolyard.me> References: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> <4B006F37.6030905@bolyard.me> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 14:22:43 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1/wSdieUYsTgbCpu/jzsgrZ3TsWWZ+UphrAdOc fJnpoIM362Zhquebee+Ph6Rjc8PK+kdAF71j7vpb5MBQaTxYcH nbCoLVQKuRT5C+9QIZPLA== Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:22:50 -0000 On Nov 15, 2009, at 1:14 PM, Nelson B Bolyard wrote: > On 2009-11-15 03:38 PDT, Eric Rescorla wrote: > >> So, thinking further on my earlier message, I think the following >> elaboration will work a bit better: >> >> - Strict clients (those which wish to insist on RI) generate RI on >> initial handshake. As I said earlier, I don't think this is >> useful, but it works. >> >> - Lenient clients do not generate RI on initial handshake but do >> generate it on rehandshake with TLS 1.0+ only. >> + Moderately lenient clients can fail if the server does not >> do RI. >> + Really lenient clients can ignore the server's failure to >> do RI. > > Aren't your so-called Lenient clients still 100% vulnerable to the > attack? > > What prevents their initial handshakes from being used by an > attacker as > renegotiations with a vulnerable server? Not connecting to a vulnerable server would. In the web browser scenario, if I know that the HTTPS servers I use for serious purposes are not vulnerable (i.e. don't allow renegotiation, other than possibly with the updated renegotiation protocol), I'm fine. When an HTTP page points me to an HTTPS page that I haven't heard of before, where I wouldn't even bother to verify the certificate's subject name or the hostname, then I don't care at all: I don't know if the entity that owns the certificate is who I think is running the site anyway. Maybe a "Man-in-the-Middle" style attacker is handling all my connections and forwarding them to the real server in TLS renegotiation handshakes -- so what? The attacker could just as well have directed me to another domain for which they have a certificate. If there's no active attacker, I'm fine to the extent that it's possible: my traffic is at least safe from passive eavesdroppers. Without a lenient client, I'll actually lose something if the servers haven't been upgraded because I might have to fall back to an unencrypted connection instead. Bodo From nelson@bolyard.me Sun Nov 15 14:33:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246FA3A6A39 for ; Sun, 15 Nov 2009 14:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.820, 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 ZJHBdGhhv+2i for ; Sun, 15 Nov 2009 14:33:44 -0800 (PST) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id 583AD3A6A34 for ; Sun, 15 Nov 2009 14:33:44 -0800 (PST) Received: (qmail 8214 invoked from network); 15 Nov 2009 22:33:43 -0000 Received: from unknown (24.5.142.42) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 15 Nov 2009 22:33:42 -0000 Message-ID: <4B00823F.3030103@bolyard.me> Date: Sun, 15 Nov 2009 14:35:43 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Bodo Moeller References: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> <4B006F37.6030905@bolyard.me> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:33:45 -0000 On 2009-11-15 14:22 PDT, Bodo Moeller wrote: > On Nov 15, 2009, at 1:14 PM, Nelson B Bolyard wrote: > >> On 2009-11-15 03:38 PDT, Eric Rescorla wrote: >> >>> So, thinking further on my earlier message, I think the following >>> elaboration will work a bit better: >>> >>> - Strict clients (those which wish to insist on RI) generate RI on >>> initial handshake. As I said earlier, I don't think this is >>> useful, but it works. >>> >>> - Lenient clients do not generate RI on initial handshake but do >>> generate it on rehandshake with TLS 1.0+ only. >>> + Moderately lenient clients can fail if the server does not >>> do RI. >>> + Really lenient clients can ignore the server's failure to >>> do RI. >> Aren't your so-called Lenient clients still 100% vulnerable to the >> attack? >> >> What prevents their initial handshakes from being used by an >> attacker as renegotiations with a vulnerable server? > > Not connecting to a vulnerable server would. In the web browser > scenario, if I know that the HTTPS servers I use for serious purposes > are not vulnerable (i.e. don't allow renegotiation, other than > possibly with the updated renegotiation protocol), I'm fine. Right. In the presence of a "white list" of known invulnerable servers, no client protocol modifications of any kind are necessary. > When an HTTP page points me to an HTTPS page that I haven't heard of > before, where I wouldn't even bother to verify the certificate's > subject name or the hostname, then I don't care at all: Right. That case is not interesting. The interesting case is the server that you have heard of before, and do use, perhaps with some frequency, but you do not know if it is vulnerable or not. Since you are a regular user of that server, if it is vulnerable then the next time you use it, you may be vulnerable, too. As a lenient client of that server, you have no protection from the attack. From bmoeller@acm.org Sun Nov 15 14:41:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE2B3A6821 for ; Sun, 15 Nov 2009 14:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.673 X-Spam-Level: X-Spam-Status: No, score=-101.673 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 pC7RNmM7cp09 for ; Sun, 15 Nov 2009 14:41:08 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 37D253A6A20 for ; Sun, 15 Nov 2009 14:41:08 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LehKM-1NzyQT0zuw-00qjDo; Sun, 15 Nov 2009 23:41:04 +0100 From: Bodo Moeller To: Nelson B Bolyard In-Reply-To: <4B007DF1.6080200@bolyard.me> References: <4B007DF1.6080200@bolyard.me> Message-Id: <06FC37B9-22B7-455A-A720-E2730054DC29@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 14:41:00 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX183PUgowlv+FqtaO6gzemMQjyHCs6BD6CO8pEo RGsiCTwl36GpAtOs7I+WHPE8GknIjhxxCvTQmrRluYm/m4U4yA 2Ld+/jWe9DsZRFQLjmKdQ== Cc: IETF TLS Working Group Subject: Re: [TLS] Safe vulnerability probing of servers possible w/o extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:41:09 -0000 On Nov 15, 2009, at 2:17 PM, Nelson B Bolyard wrote: > I believe that, if a client "knows" that a certain TLS or SSL 3.0 > server > does not perform renegotiation (has disabled renegotiation), then the > client may safely initiate TLS/SSL3 handshakes with that server, > without > any new extensions or other protocol changes. Yes. > This leads me to wonder if there is a way by which a client can > "probe" a > remote server to determine whether that server does or does not > support > renegotiation, without possibility of itself falling victim to this > renegotiation attack in the process of that probing. Is there a > "safe" > way to probe a remote server? I've thought about this too and my answer was, to some extent yes, but not entirely reliably. > It seems to me that a client might safely conduct such a probe as > follows: > > 1) Connect to the server via TCP. > 2) Initiate and complete a TLS 1.0 (or SSL 3.0) handshake, with no > session > ID (no attempt to resume any previously established session), and > with no > client authentication, and with no hello extensions. > 3) Do not send ANY application data. > 4) When the handshake is complete, immediately initiate a second > handshake > also with no session ID, with no client authentication, with no > application > data, and with no hello extensions. > 5) attempt to complete the renegotiation. Then disconnect. > > If the renegotiation completes, the server is known to be vulnerable. This is not entirely true because a server that supports renegotiation only when the connection is quiet and there's no unhandled application data around could be secure even with old-style renegotiation. I don't care too much about this special case, though: If renegotiation completes in this probe, the server is *probably* vulnerable, and we'd better flag it as such. > If it does not, then repeat the test, but in step 3, send a simple > anonymous > request (e.g. http GET / request) with no identification and > authentication > of any form (no cookies, no basic auth, etc.) > > Again, if the renegotiation completes, the server is known to be > vulnerable. Yes. > If it does not, then the probability that the server supports > renegotiation > has been established to be low. No -- maybe it's a server that will do renegotiation only if it has initiated renegotiation itself. I.e., it will only accept a new ClientHello if it has sent a HelloRequest. > I think this is "safe", in that, even if an attacker is attempting > to use > this client's initial handshake in a renegotiation attack, the client > does not provide any I&A information that could be used to authorize > the > attacker's transaction, or that the attacker could subsequently > replay. > > Are there any big holes in this scheme? Doing this probe is not dangerous (everything the clients does, the attacker could do on its own), and it will flag servers that are (probably) vulnerable. However, you won't ever be entirely certain that a server doesn't support renegotiation. Bodo From mrex@sap.com Sun Nov 15 14:42:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3846F3A6781 for ; Sun, 15 Nov 2009 14:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_50=0.001, 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 OQd0baX3UiFy for ; Sun, 15 Nov 2009 14:42:44 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CC15E3A657C for ; Sun, 15 Nov 2009 14:42:43 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAFMge80000509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 23:42:40 +0100 (MET) From: Martin Rex Message-Id: <200911152242.nAFMgdc2026889@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Sun, 15 Nov 2009 23:42:39 +0100 (MET) In-Reply-To: <20091115111834.334A869F79B@kilo.networkresonance.com> from "Eric Rescorla" at Nov 15, 9 01:18:33 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:42:45 -0000 Eric Rescorla wrote: > > > > === R5. Not using an extension to implement the fix. > > > > Currently there are no examples of extensions used in a critical role > > between interoperable systems, even where there would be significant > > gain (financial and otherwise) from their use (e.g., SNI). An urgent > > security-critical bug fix is absolutely not the place for blazing new > > trails. > > I don't find this convincing at all. > > There's a huge difference between using an extension to implement > something which we know needs changes on both sides right now and > which we want to break if both sides aren't changed and using > an extension to roll out an incremental feature that's a nice > to have (i.e., name-based virtual hosting.) If we provide the fix wrapped in a TLS extension, then updating the installed base will require careful planning, because clients sending TLS extensions will cause interop problems in existing usage scenarios. If we design the fix in a way that the risk of interop problems in existing usage scenarios is extremely low, then the end users do not have to perform careful update planning to make sure all servers are updated before the first client is updated. This interop interlocking is a severe problem because TLS is used on the internet and usually you connect to other people's servers as well, not just your own. Having to plan you update procedure for your own clients&servers is already painful, but having it to synchronize it with the update of all the other servers out there that you're using would be a royal PITA. There WILL BE a transition period, and ignoring the problems that a solution will create during that transition period is a BAD IDEA. Am I really the only one who thinks that requiring the TLS extension RI band-aid throughout eternity instead of adding the fix where it belongs--into the base protocol makes the protocol more complex than necessary and looks weird. > > 3. If we only make the minimal change, then clients will not be able > to determine whether they are connecting to a vulnerable server > even if they have no intention of renegotiating. If we want them > to be able to do so, then it's most natural to have upgraded > servers behave differently on the initial negotiation. The "minimal" change should include signaling, of course, but work entirely without extensions, in particular without sending the verify_data over the wire, because that is entirely unnecessary in order to protect the renegotiation. Why should we send the stuff over the network when we know exactly that it is unnecessary and just compilicates the protocol, complicates implementations and wastes network bandwidth? > > I should add that I don't really think this functionality is that > useful. Because the simplest fix is to simply disable > renegotiation, many servers will do just that, regardless of how > compatible the client's offer of a newer version is. I find it > highly implausible that people who are currently running OpenSSL > 0.9.7x are going to suddenly install a version which responds to a > fake cipher suite by upgrading to TLS version 1.3! Why are you talking about TLS v1.3 here? I have not seen anyone suggesting upgrade to TLSv1.3. I'm asking to stay on SSLv3 and/or TLSv1.0 with a TLS renegotiation fix. TLSv1.3 was only mention in the context that it should no longer support the old TLS renegotiation at all, no further signalling required. > (a) Send RI on the initial handshake. > (b) Send something else (e.g., a fake cipher suite) on the initial handshake. > (c) Have the server send something unsolicited, e.g., a fixed portion of > the ServerRandom. There is absolutely no need for the server to send anything unless the client has clearly indicated that it will understand that something perfectly well! In that respect, there is no difference between RI and my proposal. > > The major problem (to the extent it is a problem) with offering RI on > the initial handshake is that it may cause interop failures with some > servers which don't support TLS extensions properly. In order for this > to be an issue however, you have to believe that: > > (1) The client wishes to be able to detect that servers have not > been upgraded. > (2) The client isn't going to outright fail when it encounters > such servers. > (3) The client can't deal with a reconnect given (2) and (3). > > I don't really find this set of assumptions very plausible. Clients > which care enough to actually probe the server to determine if it > has been upgraded need to do something with that information. The fact that there are Browsers that actually "probe" indicates that we have non-negligable interop problems with TLS procotol version and TLS extensions. The largest part of programmatic clients and Browsers that are not bleeding-edge do NOT probe and neither want to probe servers. They just want to signal servers that they are capable of secure renegotiation. And they want to be able to signal that to the entire world without having to fear that a fraction of the servers that these clients talk to will choke and close the connection. This problem will be particularly severe during the transistion period between today (where no patched servers exist) and somewhere late next year, when most servers will have been patched. Breaking existing usage scenarios out of negilgence is poor engineering. Not just for software vendors shipping updates to the customers, but also for and IETF working group trying to fix a protocol defect. > > 4. The other argument offered in favor of avoiding extensions is > that we want to be able to provide upgraded SSLv3 implementations. > I'm unconvinced that there are a significant number of > applications which: > > (1) Can't use TLS. - there definitely are. - if the solution for the TLS renegotiation weakness does not describe how to use it on connections that are negotiated with protocol version 0x03,0x00, then such a solution is a failure > > (2) Do renegotiation. They ususally don't use reneogitation on the server side. However they can do it on the client side, therefore it is extremely important that the solution specifies how to renegotiate securely with protocol version 0x03,0x00 > > (3) Are going to upgrade their stacks to support some new > secure renegotiation thing change. yes, everyone that has shipped SSL or TLS and charges for maintenance is going to fix his code. > > (4) Won't just upgrade to TLS. There are many more implementations of TLS than just those that you know. And since TLS specifies only wire-formats and protocol, but nothing about API and credentials management, there is _NO_ simple plug'n'play between TLS implementations of different vendors. The option "to just upgrade" simply does not exist for a number of consumers of TLS, since their implementation exists only for the particular protocol version that they're using. And even those who do use an implementation from one of the well-known providers -- those who use it in productive environment can not simply plugin the most recent release of the software, because it is going to affect at least some of the actively used scenarios. The TLS renegotiation vulnerability is a flaw in the protocol that can be fixed entirely within the base protocol and the TLS implementation and with a minimal risk of affecting existing usage scenarios, in particular during the transistion period. -Martin From bmoeller@acm.org Sun Nov 15 14:43:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E473A67A7 for ; Sun, 15 Nov 2009 14:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.769 X-Spam-Level: X-Spam-Status: No, score=-101.769 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 KMGRj+pt6Ara for ; Sun, 15 Nov 2009 14:43:36 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 6B8EB3A6781 for ; Sun, 15 Nov 2009 14:43:36 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LjweT-1NlLcx0HgP-00bjHZ; Sun, 15 Nov 2009 23:43:31 +0100 From: Bodo Moeller To: Nelson B Bolyard In-Reply-To: <4B00823F.3030103@bolyard.me> References: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> <4B006F37.6030905@bolyard.me> <4B00823F.3030103@bolyard.me> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 14:43:27 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1/BzMq9Cr+Qw3jqPETkpZNUBhjlmZfPTrctxYT 2w0QIZdko3CUs7NeeMth9xCJL+pMO5bbdTuLREr/rFpA0Ztto9 5DmfDQh0InezDvSuXMDxQ== Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:43:37 -0000 On Nov 15, 2009, at 2:35 PM, Nelson B Bolyard wrote: > The interesting case is the server that you have heard of before, > and do > use, perhaps with some frequency, but you do not know if it is > vulnerable > or not. Since you are a regular user of that server, if it is > vulnerable > then the next time you use it, you may be vulnerable, too. As a > lenient > client of that server, you have no protection from the attack. Yes. Using a lenient client means the responsibility to protect against the attack is with the server. Bodo From marsh@extendedsubset.com Sun Nov 15 14:51:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259823A6995 for ; Sun, 15 Nov 2009 14:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.783, 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 DtVnfV5cMT-3 for ; Sun, 15 Nov 2009 14:51:37 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 5B7223A6840 for ; Sun, 15 Nov 2009 14:51:37 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9nwW-0004VP-FB for tls@ietf.org; Sun, 15 Nov 2009 22:51:36 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 50171667C for ; Sun, 15 Nov 2009 22:51:35 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18C1dc40ph/H3cQTzGSgRj25iQRhlYvMeU= Message-ID: <4B0085F5.1010905@extendedsubset.com> Date: Sun, 15 Nov 2009 16:51:33 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4AFF79A4.6020706@extendedsubset.com> <67C27EB3-804A-4A5D-91C1-451FCD684D21@acm.org> In-Reply-To: <67C27EB3-804A-4A5D-91C1-451FCD684D21@acm.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:51:38 -0000 Bodo Moeller wrote: > > I don't agree that the fix must fully work for SSL 3.0. There is currently a massive amount of SSLv3 traffic. Sure, much of it is because people aren't being proactive about upgrading. A significant amount of it we must assume is because there are real difficulties in upgrading. > A fix that simply disallows renegotiation for SSL 3.0 (while updating > the renegotiation protocol for TLS 1.0 and later -- or also for the "SSL > 3.0 with TLS extensions" hybrid) could not be bypassed by the attacker. If there are client cert credentials in the initial handshake, those could be stolen and forwarded to another server. Be careful what you ask for, for many sites it is far easier to just disable renegotiation entirely than to get 100% off of SSLv3 in the timeframe of a security fix. There are entire business, development models, and security infrastructures built on https renegotiation. We mustn't fail them by allowing the majority to effectively deprecate what is a legitimate part of the protocol. - Marsh From bmoeller@acm.org Sun Nov 15 14:52:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29143A6765 for ; Sun, 15 Nov 2009 14:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.837 X-Spam-Level: X-Spam-Status: No, score=-101.837 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ARgs7FMsLk0W for ; Sun, 15 Nov 2009 14:52:28 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 9E55F3A6853 for ; Sun, 15 Nov 2009 14:52:27 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Larzk-1NtuKy1YD2-00kxrv; Sun, 15 Nov 2009 23:52:21 +0100 From: Bodo Moeller To: mrex@sap.com In-Reply-To: <200911152242.nAFMgdc2026889@fs4113.wdf.sap.corp> References: <200911152242.nAFMgdc2026889@fs4113.wdf.sap.corp> Message-Id: <45EEC3B9-4A73-4811-B0F2-817C6D6B9748@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 14:52:17 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX19S+WlrP8J01KfsU0tjpLuyrozZ9uP712xNpgz Bj1OwQuKNbEc4PUalGzA1hS+Px6lqMKAFmr+BnOthiVD6YJL2c L1DhsHJWUE9i4YeuYZ4Og== Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:52:28 -0000 On Nov 15, 2009, at 2:42 PM, Martin Rex wrote: > This interop interlocking is a severe problem because TLS is used > on the internet and usually you connect to other people's servers > as well, not just your own. Having to plan you update procedure > for your own clients&servers is already painful, but having it > to synchronize it with the update of all the other servers out > there that you're using would be a royal PITA. > > > There WILL BE a transition period, and ignoring the problems that > a solution will create during that transition period is a BAD IDEA. I fully agree. > Am I really the only one who thinks that requiring the > TLS extension RI band-aid throughout eternity instead of adding > the fix where it belongs--into the base protocol makes the > protocol more complex than necessary and looks weird. As I said, the approach of using the previous Finished messages as "virtual handshake message" (I think that's the term you used) for the new verify_data looks good. This requires some signal for current protocol versions, and no additional signal for a newer protocol version where this would be standard. This signal could be a TLS extension -- arguably band-aid, but not needed throughout eternity. Furthermore, as this would be a *fixed* TLS extension (no content required), this should be easy to add even to implementations that don't really support TLS extensions: For the client side, it's an entirely fixed value to append to the Client Hello; for the server side, it's a fixed value to search for in the client_hello_extension_list (and a fixed value to append to the Server Hello). Bodo From marsh@extendedsubset.com Sun Nov 15 14:55:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159573A6853 for ; Sun, 15 Nov 2009 14:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.685, 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 LAPJotYLAmjQ for ; Sun, 15 Nov 2009 14:55:32 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 5227F3A657C for ; Sun, 15 Nov 2009 14:55:32 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9o0J-0005dg-DQ for tls@ietf.org; Sun, 15 Nov 2009 22:55:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8474C667C for ; Sun, 15 Nov 2009 22:55:30 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/GHiKw2T1yahv8n9xVZIuU0URPtz2Ar8c= Message-ID: <4B0086E0.8050904@extendedsubset.com> Date: Sun, 15 Nov 2009 16:55:28 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls >> \"tls@ietf.org\"" References: <4B007DF1.6080200@bolyard.me> In-Reply-To: <4B007DF1.6080200@bolyard.me> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Safe vulnerability probing of servers possible w/o extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:55:33 -0000 Nelson B Bolyard wrote: > > It seems to me that a client might safely conduct such a probe as follows: > > 1) Connect to the server via TCP. > 2) Initiate and complete a TLS 1.0 (or SSL 3.0) handshake, with no session > ID (no attempt to resume any previously established session), and with no > client authentication, and with no hello extensions. > 3) Do not send ANY application data. > 4) When the handshake is complete, immediately initiate a second handshake > also with no session ID, with no client authentication, with no application > data, and with no hello extensions. IIS serves will hang up on you right there. > Are there any big holes in this scheme? Attacker can simulate a safe server when you probe it, yet exploit you with a vulnerable server once you trust it. - Marsh From yngve@opera.com Sun Nov 15 14:56:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C483A6A40 for ; Sun, 15 Nov 2009 14:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 qYeaHSw-II5k for ; Sun, 15 Nov 2009 14:56:46 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 343CC3A6A3F for ; Sun, 15 Nov 2009 14:56:46 -0800 (PST) Received: from acorna.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAFMtVmm006532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Nov 2009 22:55:32 GMT Date: Sun, 15 Nov 2009 23:56:28 +0100 To: "Nelson B Bolyard" , "IETF TLS Working Group" From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <4B007DF1.6080200@bolyard.me> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4B007DF1.6080200@bolyard.me> User-Agent: Opera Mail/9.65 (Win32) Subject: Re: [TLS] Safe vulnerability probing of servers possible w/o extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:56:47 -0000 Nelson, Opera may be the client with the most complex TLS feature discovery mechanism, and it is IMO too complex already, so I am not going to be adding such a mechanism to Opera. What I am intending to implement in Opera, whenever the WG settles on a mechanism where the client and server can exchange information about their secure renegotiation capability, is the following: Stage 1: Inform the user in secondary chrome about servers that does not support secure renegotiation Stage 2: At some time in the future Opera installations will start warning the user through warning dialogs that the server may not be secure. At this stage the sites will also lose the padlock indication. Stage 3: Some time after that Opera will start refusing to establish connections with such servers. The functionality for these three stages will be built into the first version we ship with the new functionality, and will be controlled by an auto-update preference that is already (in Opera 10) controlling similar stage 2 and 3 functionality for MD5 and SHA-1 support in certificates, and for SSL v3 support. IMO the dates for stage 2 and stage 3 should be included, as MUSTs, in the RFC for the specification that comes out of this discussion. The reason for this is, brutally put, that if there is no sunset for the unpatched servers, then the work on a protection mechanism is wasted effort. In a transition period clients will have to support unpatched servers, but the length of the period should be clear from day one. IMO the transition period should be much closer to 1 year than 5 years. On Sun, 15 Nov 2009 23:17:21 +0100, Nelson B Bolyard wrote: > I believe that, if a client "knows" that a certain TLS or SSL 3.0 server > does not perform renegotiation (has disabled renegotiation), then the > client may safely initiate TLS/SSL3 handshakes with that server, without > any new extensions or other protocol changes. > > This leads me to wonder if there is a way by which a client can "probe" a > remote server to determine whether that server does or does not support > renegotiation, without possibility of itself falling victim to this > renegotiation attack in the process of that probing. Is there a "safe" > way to probe a remote server? > > It seems to me that a client might safely conduct such a probe as > follows: > > 1) Connect to the server via TCP. > 2) Initiate and complete a TLS 1.0 (or SSL 3.0) handshake, with no > session > ID (no attempt to resume any previously established session), and with no > client authentication, and with no hello extensions. > 3) Do not send ANY application data. > 4) When the handshake is complete, immediately initiate a second > handshake > also with no session ID, with no client authentication, with no > application > data, and with no hello extensions. > 5) attempt to complete the renegotiation. Then disconnect. > > If the renegotiation completes, the server is known to be vulnerable. > If it does not, then repeat the test, but in step 3, send a simple > anonymous > request (e.g. http GET / request) with no identification and > authentication > of any form (no cookies, no basic auth, etc.) > > Again, if the renegotiation completes, the server is known to be > vulnerable. > If it does not, then the probability that the server supports > renegotiation > has been established to be low. > > I think this is "safe", in that, even if an attacker is attempting to use > this client's initial handshake in a renegotiation attack, the client > does not provide any I&A information that could be used to authorize the > attacker's transaction, or that the attacker could subsequently replay. > > Are there any big holes in this scheme? > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From mrex@sap.com Sun Nov 15 14:56:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCCF3A6A3F for ; Sun, 15 Nov 2009 14:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.545 X-Spam-Level: X-Spam-Status: No, score=-5.545 tagged_above=-999 required=5 tests=[AWL=0.704, 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 NBLIlq-poNpP for ; Sun, 15 Nov 2009 14:56:47 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 549483A6A1F for ; Sun, 15 Nov 2009 14:56:47 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAFMufEd008928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 23:56:41 +0100 (MET) From: Martin Rex Message-Id: <200911152256.nAFMuf0H027702@fs4113.wdf.sap.corp> To: bmoeller@acm.org (Bodo Moeller) Date: Sun, 15 Nov 2009 23:56:41 +0100 (MET) In-Reply-To: <67C27EB3-804A-4A5D-91C1-451FCD684D21@acm.org> from "Bodo Moeller" at Nov 15, 9 02:03:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 22:56:48 -0000 Bodo Moeller wrote: > > On Nov 14, 2009, at 7:46 PM, Marsh Ray wrote: > > > === R6. The fix must work for SSLv3. > > > > One source measured 22% of current SSL/TLS traffic still over SSLv3, > > and > > other sources of data have tended to confirm that. This is far too > > large > > a group to ignore, or expect to "just upgrade". > > > > Even software that does support newer versions of the protocol will > > often fall back to SSLv3 at the first sign of trouble. Any fix which > > does not address SSLv3 can simply be bypassed by the attacker > > I don't agree that the fix must fully work for SSL 3.0. > > A fix that simply disallows renegotiation for SSL 3.0 (while updating > the renegotiation protocol for TLS 1.0 and later -- or also for the > "SSL 3.0 with TLS extensions" hybrid) could not be bypassed by the > attacker. It is completely trivial to design the fix so that it works for ALL protocol version SSLv3->TLSv1.2 It would be unreasonable and irresponsible to design the fix in a fashion that is hard to apply to SSLv3 or to remain entirely silent in the solution how the fix works for TLS session negotiated with protocol version 0x03,0x00. Most of the installed base using 0x03,0x00 is _not_ broken. The servers that are using renegotiation, and most of these use newer TLS implementations, are the ones that are vulnerable. -Martin From marsh@extendedsubset.com Sun Nov 15 15:05:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94B23A6853 for ; Sun, 15 Nov 2009 15:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.609, 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 7nODb+AHH7-t for ; Sun, 15 Nov 2009 15:05:07 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 1424B3A6840 for ; Sun, 15 Nov 2009 15:05:07 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9o9a-0007Pn-55 for tls@ietf.org; Sun, 15 Nov 2009 23:05:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2AB8A667C for ; Sun, 15 Nov 2009 23:05:05 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+xDcnATmAozBTQPR1GwB6nWkE6VfJVyHA= Message-ID: <4B00891E.3050100@extendedsubset.com> Date: Sun, 15 Nov 2009 17:05:02 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911152242.nAFMgdc2026889@fs4113.wdf.sap.corp> In-Reply-To: <200911152242.nAFMgdc2026889@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:05:07 -0000 Martin Rex wrote: > > Am I really the only one who thinks that requiring the > TLS extension RI band-aid throughout eternity instead of adding > the fix where it belongs--into the base protocol makes the > protocol more complex than necessary and looks weird. I think so. :-) If RI gets deployed as hello extensions and it works, don't mess with it. Just because the sub-structure's name has the word "extension" doesn't make it a band-aid or even not part of the base protocol. Protocols have a long tradition of defining "required options" and "optional options". On the other hand, if you're saying something deeper (say about mac calculation or whatever) needs to change that could be an interesting point, but don't detract from it by mixing it up with objections to the "extension" label. - Marsh From bmoeller@acm.org Sun Nov 15 15:08:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA813A6853 for ; Sun, 15 Nov 2009 15:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.889 X-Spam-Level: X-Spam-Status: No, score=-101.889 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 x7jNE5U0B2ya for ; Sun, 15 Nov 2009 15:08:57 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 1EC773A6765 for ; Sun, 15 Nov 2009 15:08:57 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LswsU-1OC6v93vL8-011ych; Mon, 16 Nov 2009 00:08:55 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4B0085F5.1010905@extendedsubset.com> References: <4AFF79A4.6020706@extendedsubset.com> <67C27EB3-804A-4A5D-91C1-451FCD684D21@acm.org> <4B0085F5.1010905@extendedsubset.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 15:08:51 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX18YxB5shud91mJ8uMuelrzJQTYf0dLdRpvlQ2n I9cEVDtJKwOxUKRctvsIBOTAsPUoc+ORJBCX7y/iqf48YelS6C I7zM3RnmqfkJLZuwQsycQ== Cc: "tls@ietf.org" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:08:58 -0000 On Nov 15, 2009, at 2:51 PM, Marsh Ray wrote: > Bodo Moeller wrote: >> >> I don't agree that the fix must fully work for SSL 3.0. > > There is currently a massive amount of SSLv3 traffic. How much of this does involve renegotiation, though? For current SSL 3.0 traffic involving renegotiation, how much of this is SSL 3.0 just because newer client or server software hasn't been *installed* in a while? A software upgrade would be needed anyway for anyone hoping to use a new SSL 3.0 renegotiation feature. Where protocol versions newer than SSL 3.0 are currently available anyway (just not installed), no new SSL 3.0 feature would be needed. For software packages where even the *current* version only has SSL 3.0 (and supports renegotiation), yes, a fix that works for SSL 3.0 would be nice. The mere amount of SSL 3.0 traffic doesn't tell us anything about how many these are, though. > Sure, much of it > is because people aren't being proactive about upgrading. A > significant > amount of it we must assume is because there are real difficulties in > upgrading. I can't really believe that the upgrade to a modified SSL 3.0 (with secure renegotiation) would be much easier in these cases, though ... Anyway, a simple protocol fix (using extensions without content, say) should work reasonably well even with SSL 3.0 > >> A fix that simply disallows renegotiation for SSL 3.0 (while updating >> the renegotiation protocol for TLS 1.0 and later -- or also for the >> "SSL >> 3.0 with TLS extensions" hybrid) could not be bypassed by the >> attacker. > > If there are client cert credentials in the initial handshake, those > could be stolen and forwarded to another server. How so? The client supposedly will authenticate the server it is sending a certificate to (and to the extent that it matters, "It is a fatal handshake_failure alert for an anonymous server to request client identification" according to the specs). Bodo From mrex@sap.com Sun Nov 15 15:24:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994BC3A6A1F for ; Sun, 15 Nov 2009 15:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.901 X-Spam-Level: X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, 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 VfSXLgzAr7ap for ; Sun, 15 Nov 2009 15:23:59 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 64FB73A6832 for ; Sun, 15 Nov 2009 15:23:59 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAFNNsrU022877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 00:23:54 +0100 (MET) From: Martin Rex Message-Id: <200911152323.nAFNNr9f029282@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Mon, 16 Nov 2009 00:23:53 +0100 (MET) In-Reply-To: <4B007DF1.6080200@bolyard.me> from "Nelson B Bolyard" at Nov 15, 9 02:17:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Safe vulnerability probing of servers possible w/o extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:24:00 -0000 Nelson B Bolyard wrote: > > I believe that, if a client "knows" that a certain TLS or SSL 3.0 server > does not perform renegotiation (has disabled renegotiation), then the > client may safely initiate TLS/SSL3 handshakes with that server, without > any new extensions or other protocol changes. > > This leads me to wonder if there is a way by which a client can "probe" a > remote server to determine whether that server does or does not support > renegotiation, without possibility of itself falling victim to this > renegotiation attack in the process of that probing. Is there a "safe" > way to probe a remote server? > > It seems to me that a client might safely conduct such a probe as follows: First of all, the idea that clients need to probe servers is a fatally flawed idea. There is a part of the TLS protocol called handshake which is supposed to negotiate an interoperable set of protocol features to perform a communication. Clients simply want to connect to some servers and talk to them secrely. Client do _NOT_ want to probe servers and they do not want to maintain lists of servers and the protocol features they support in order to be able to talk to them. When it happens to TLS that clients need to start doing this in order to be able to talk to a server on first connect, then we have really fucked up the protocol. > > [complex probing scenario deleted] > > Are there any big holes in this scheme? It looks like a number of daring assumptions. TLS session IDs are assigned by the server and at the discretion of the server, the client has no say in this. MS IIS does not accept unsolicited renegotiations, Marsh mentioned that it will close the connection. Really, out best bet is to make this fix a simple as possible and equally suited for all protocol version 0x03,0x00->0x03,0x03 and then we may actually come to the point where we can stop talking to unpatched servers. If the fix requires a TLS extension, does _not_ cover SSLv3 and requires a TLS extension in the ClientHello in the initial handshake of a connection, then it - will cause interop problems during the transition - which will require careful patch installation planning - which will slow down adoption of the patch considerably and lengthen the transition period by factors - which, all in all, will unnecesarily cost a lot of people a lot of time and money - and has a much higher risk to leave a non-negligable amount of unpatched servers at the end of the transition period. Therefore, we should really change the signaling to something that is more backwards compatible and easier to implement. Drop the exchange of the finished messasges from the renegotiation handshake entirely and adjust the definition of the handshake message hash that goes into the CertificateVerify and the Finished messsage instead to include the verify_data of the client.finished and server.finished message instead on a renegotiation handshake. I have not seen one single disadvantage to this approach on this list. -Martin From mike-list@pobox.com Sun Nov 15 15:31:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA563A6832 for ; Sun, 15 Nov 2009 15:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] 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 d85fAH4D12cn for ; Sun, 15 Nov 2009 15:31:02 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 0A43A3A6765 for ; Sun, 15 Nov 2009 15:31:01 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C3FCD80AD2 for ; Sun, 15 Nov 2009 18:30:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=+NYDcU9Z9s9EB4pyzX62pC9Ph wQ=; b=J6v2QOCMosZuvqzgmvutl7VUgmv4opf1OtzmgppFngv9zjM3HSsEunQha NCjXnaU0XIN+VOSHZPqND7MseKZsmX7MPreGmow71z2wCoaQcDM5zYXZ4zUh08KH CszkYN152FfGieUvjqyeo/XN2l0B/Dj7Xq/ln3VNmkS8iE4xLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=ly2cj24KAt/MqLkHGtr ziShR7W1aPyNnO20ohU4wL8ekrwJw3DESI4SPlg6Go56IKEszRa3hYXaMS+SOOLN r3yCVJ4Y3Lq5Qe0ZaqEpaUQF0pKHIU1sB1Trq0pMFkBJMrRPjQtJ5qFIfC2ctS02 wPCkyQduEHh4rmFT4U9iQVII= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C0F8880AD1 for ; Sun, 15 Nov 2009 18:30:59 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 26B7880AD0 for ; Sun, 15 Nov 2009 18:30:59 -0500 (EST) Message-ID: <4B008F6D.7070303@pobox.com> Date: Sun, 15 Nov 2009 15:31:57 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: EE6CDF2E-D23E-11DE-B27A-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:31:03 -0000 Whatever the solution turns out to be, I think we all agree that it needs to address these two simple issues: 1) A server needs to be able to protect against MITM attacks 2) A client needs to be able to protect against MITM attacks Solving #1 is trivial since a server can simply refuse to renegotiate a connection when the client doesn't use the agreed-upon solution. Solving #2 is more difficult, and it breaks down into the following two sub-issues: 2a) A client needs to be able to protect against attacks when the server is patched 2b) A client needs to be able to protect against attacks when the server is NOT patched Issue 2a is again trivially accomplished by the fact that the server is protecting the client (issue 1, since it is patched), so the important case is 2b and ONLY 2b, i.e. patched client / unpatched server. Here is an analysis of whether proposed solutions address this case 2b: RI with patched client / unpatched server: People continue to suggest that with the RI extension, a client doesn't need to send it on its initial handshake. This is completely wrong. A MITM attack will absolutely succeed if the server is not patched and the client does nothing different than it always has in the past. Thus if RI is not used by the client in its first handshake, it gets zero protection even though it is aware of the MITM attack. And even if the client does use the extension, it must rely on a possibly forged Server Hello to decide whether to continue with the handshake. So the client has to send the extension on every handshake including the initial handshake. This brings up all of the interoperability problems: lack of support for extensions even in TLS, no possible way to use extensions with SSLv3, mischief by a MITM (removing the extension from the hello messages, simulating a server "crash" when the extension is sent, etc.) This is at best "treacherous". Modifying the Finished message calculation: If instead of RI we change the Finished message calculation, it needs to protect patched clients that connect to unpatched servers (the only case that matters -- see above). If the Finished message calculation were to remain the same on initial handshakes, then again the client gets absolutely no protection when connecting to an unpatched server since it will use the old unchanged calculation even on renegotiations. Here is my proposal for a backward-compatible solution that also protects the important case 2b above: This solution is to make available a modified Finished calculation that a patched client can use for all handshakes including the initial one. This solution does not even break compatibility with old clients -- a server would support BOTH the old and the new Finished message computation and do the right thing based on which one was used by the client. There are only two possibilities: A) client uses the old (current) Finished calculation B) client uses the new Finished calculation With (A), the server would allow an initial connection but prevent any renegotiations, thus protecting against any MITM attacks. If the client uses the new Finished calculation (B), then the handshake succeeds whether it was an initial handshake or a renegotiation. If neither calculation matches, the server knows that there was tampering by a MITM, and should not continue with the handshake. We never need to stop supporting the old method for initial handshakes, so this is completely backward-compatible for clients connecting to a new server when renegotiation is not involved. If renegotiation is required to use the server, then the current type of insecure renegotiations are prevented as we want. The only interoperability "problem" is when a patched client uses the new Finished calculation when talking to an unpatched server[*] -- the handshake will fail. This is precisely what SHOULD happen -- the client is protected from a potential MITM attack! A client that does not want this protection does not need to use it. Or if it is daring it can first try the new and fall back to the old method if it's willing to risk an attack. When the server is patched and the client is convinced to fall back due to MITM meddling, the server will reliably know this and can notify the proper people to investigate the attack. [*] A minimally-patched server might simply disable all renegotiation and not want to support a new Finished calculation. To signal this, the server could do something special with the ServerHello.random, such as computing a checksum of size x bytes over the first 32-x bytes (x needs to be small enough to keep the random actually mostly random, but big enough to make false positives unlikely). Upon validating the checksum, a client could at its discretion continue the handshake using the old Finished message calculation. A MITM could forge the checksum, but then the handshake would fail anyway due to mismatched verify_data. Mike From jsalowey@cisco.com Sun Nov 15 15:35:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCDC3A6832 for ; Sun, 15 Nov 2009 15:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 iLoLdIqdwhSm for ; Sun, 15 Nov 2009 15:35:09 -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 22F503A6765 for ; Sun, 15 Nov 2009 15:35:09 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADkfAEurR7Hu/2dsb2JhbAC8W5YZhDwE X-IronPort-AV: E=Sophos;i="4.44,747,1249257600"; d="scan'208";a="433272892" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Nov 2009 23:35:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAFNZ8E6022132; Sun, 15 Nov 2009 23:35:08 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.3959); Sun, 15 Nov 2009 15:35:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 15:35:07 -0800 Message-ID: In-Reply-To: <200911151913.nAFJDIHA015276@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] To extend or not to extend Thread-Index: AcpmJ7M+WbgxRhySQZuY7s0hmzvpEAAIsoIw References: from "Joseph Salowey" at Nov 15, 9 03:13:01 am <200911151913.nAFJDIHA015276@fs4113.wdf.sap.corp> From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 Nov 2009 23:35:08.0754 (UTC) FILETIME=[44936B20:01CA664C] Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:35:10 -0000 > >=20 > > E. The RI proposal has an issue if the client is patched and the=20 > > server does not implement the SSL 3.0 and the TLS 1.x specs=20 > correctly=20 > > and the client as a lenient policy which allows connection=20 > to insecure servers. > > In this case the client would have to implement some fallback logic=20 > > (reconnect without extensions) to deal with broken servers. This=20 > > logic is well-known, but it leaves a roll-back attack open.=20 > This can=20 > > be plugged by using the proposed ciphersuite signal only in=20 > the case=20 > > where extensions cause a handshake or connection failure. The=20 > > fallback cipher-suite signaling for RI to prevent rollback=20 > extends TLS=20 > > in an unexpected way, but this is limited only to the case where we=20 > > have to deal with broken implementations. > >=20 > > Situation E is one that we expect to get less common=20 > because we want=20 > > all implementations to get patched and clients may start=20 > requiring the fix > > because this is the only way they can protect themselves. =20 > =20 > Situation E is the Killer for the TLS extension RI. >=20 > You can not seriously propose that people add reconnect=20 > fallbacks to all their applications in order to be able to=20 > use TLS extension RI in their clients during the transittion=20 > period and then after the transition period ask the apps to=20 > dump that huge amounts of code they had to implement because=20 > it is also a security problem. >=20 >=20 > With the current installed base, using TLS extension to wrap=20 > the fix is a non-starter. >=20 [Joe] Eric pointed out that if you are going to have a lenient policy that you don't need to send the extension in the initial handshake. =20 > > > > The ciphersuite-changes-handshake proposal has similar properties=20 > > except we expect that there are few broken servers that=20 > will barf on=20 > > an unknown ciphersuite (Situation E). This proposal=20 > extends TLS in a=20 > > non-standard place by having the presence of a specific ciphersuite=20 > > act as a side channel to change the behavior of the TLS=20 > handshake for all current > > versions of TLS. I don't think this is something that we=20 > would want to > > promote in the future, the code to handle this would be=20 > "one-off" code. > >=20 > > From a functional point of view I don't see any difference=20 > between A)=20 > > RI extension with option ciphersuite signal in the case of fallback=20 > > for broken servers and B) ciphersuite-changes-handshake proposal. >=20 > If we use signaling through special ciphersuite ID, then we=20 > do not need the TLS extension anymore. >=20 > The real problem of the TLS extension RI is the presence of=20 > the TLS extension on the initial handshake. If you remove=20 > the TLS extension RI from the ClientHello of the initial=20 > handshake, then the interop problems will go away. Only the=20 > superfluous waste of network bandwidth on the renegotiation remains. >=20 [Joe] OK, right. SO it seems that situation E with RI is not as bad as I stated. =20 From bmoeller@acm.org Sun Nov 15 15:36:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC24F3A688E for ; Sun, 15 Nov 2009 15:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.929 X-Spam-Level: X-Spam-Status: No, score=-101.929 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 wW1Rwm8Wh4KU for ; Sun, 15 Nov 2009 15:36:36 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id BDE533A6832 for ; Sun, 15 Nov 2009 15:36:35 -0800 (PST) Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MbrOw-1NT8i91Sn0-00IiSQ; Mon, 16 Nov 2009 00:36:33 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4B0066C9.9090901@extendedsubset.com> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> <4B005E54.6030600@extendedsubset.com> <4B0062EA.8060906@extendedsubset.com> <1F698852-2C4B-4F21-8B4F-0D6CFA6BB41E@acm.org> <4B0066C9.9090901@extendedsubset.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 15:36:28 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+TnyRFCfG3Hrnah+Bc23tLouZkEVDPY4sGyJu f3du0PtGM8BRVR5jSCXuQsy03Y5eIJhlroapq0s4Jw3G7GDx73 Xzx0KvIUSONtf7nVlp5bw== Cc: "tls@ietf.org" Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:36:36 -0000 On Nov 15, 2009, at 12:38 PM, Marsh Ray wrote: > Bodo Moeller wrote: >> >> How would they do that? Everything is supposed to be encrypted then. > > They will notice handshake messages after the initial handshake. The > record content type field is never encrypted. Oh, so you meant *potentially* unsafe renegotiations. > >> I don't think the protocol should too much be designed around making >> monitoring systems happy. You can't do this for all interesting >> issues >> that client or server implementations might have anyway. Here we >> have a >> vulnerability that's easy to fix in such a way that monitoring >> systems >> can see some fix deployment information, so why not. Adding extra >> flags >> just for monitoring's sake, I'm not so sure. > > Many, many sites will configure their stateful firewalls to shoot down > any potentially-unsafe renegotiations. Without plaintext indicators, > that will mean all renegotiations. Not sending the extension when you don't intend to abort if the server doesn't echo it back and don't intend to renegotiate seems right then. Bodo From ekr@networkresonance.com Sun Nov 15 15:45:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9798F3A6A33 for ; Sun, 15 Nov 2009 15:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHRU-hu-pFLj for ; Sun, 15 Nov 2009 15:45:31 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id A1C723A6765 for ; Sun, 15 Nov 2009 15:45:31 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9oT5-0002T8-00 for tls@ietf.org; Mon, 16 Nov 2009 01:25:15 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 0DADD69F838; Mon, 16 Nov 2009 01:26:31 +0200 (EET) Date: Mon, 16 Nov 2009 01:26:31 +0200 From: Eric Rescorla To: Nelson B Bolyard In-Reply-To: <4B006F37.6030905@bolyard.me> References: <20091115113857.4E04D69F7B2@kilo.networkresonance.com> <4B006F37.6030905@bolyard.me> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115232632.0DADD69F838@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] To extend or not to extend X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:45:32 -0000 At Sun, 15 Nov 2009 13:14:31 -0800, Nelson B Bolyard wrote: > > On 2009-11-15 03:38 PDT, Eric Rescorla wrote: > > > So, thinking further on my earlier message, I think the following > > elaboration will work a bit better: > > > > - Strict clients (those which wish to insist on RI) generate RI on > > initial handshake. As I said earlier, I don't think this is > > useful, but it works. > > > > - Lenient clients do not generate RI on initial handshake but do > > generate it on rehandshake with TLS 1.0+ only. > > + Moderately lenient clients can fail if the server does not > > do RI. > > + Really lenient clients can ignore the server's failure to > > do RI. > > Aren't your so-called Lenient clients still 100% vulnerable to the attack? > > What prevents their initial handshakes from being used by an attacker as > renegotiations with a vulnerable server? Absolutely nothing. As far as I know, the only way to avoid that is to refuse to connect to any server that you can't verify is upgraded, which, at least for the moment, is basically the same as saying you can't connect with a very substantial fraction of the Internet. It might well be possible to probe as you suggest in a subsequent message, but I don't think there's going to be a good way inside TLS... -Ekr From ekr@networkresonance.com Sun Nov 15 15:45:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535183A6A33 for ; Sun, 15 Nov 2009 15:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyZuamdnd+N4 for ; Sun, 15 Nov 2009 15:45:32 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 4FB833A6A22 for ; Sun, 15 Nov 2009 15:45:32 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9ocd-00059Q-00 for tls@ietf.org; Mon, 16 Nov 2009 01:35:07 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D241969F840; Mon, 16 Nov 2009 01:36:22 +0200 (EET) Date: Mon, 16 Nov 2009 01:36:22 +0200 From: Eric Rescorla To: Bodo Moeller In-Reply-To: <54186B27-2E2C-4DCD-B8C5-7239FBABB631@acm.org> References: <4AFC5D80.2030101@pobox.com> <4AFD91D1.7030409@pobox.com> <4AFDB8DF.4010608@pobox.com> <20091113231013.8676669F516@kilo.networkresonance.com> <54186B27-2E2C-4DCD-B8C5-7239FBABB631@acm.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115233622.D241969F840@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Two Opaque Values in Renegotiation_Info (was Re: webex) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:45:33 -0000 At Sun, 15 Nov 2009 11:58:15 -0800, Bodo Moeller wrote: > > On Nov 13, 2009, at 3:10 PM, Eric Rescorla wrote: > > > At Fri, 13 Nov 2009 11:51:59 -0800, > > Michael D'Errico wrote: > > >> I noticed in the logs that there was discussion of wanting to > >> have two separate opaque values, I assume one for the client > >> verify data and the other for the server verify data. > > > As far as I know this is not being actively considered. > > There's no point in having these two values sent in the same message. > Using two fields would break backwards compatibility with draft- > rescorla-tls-renegotiation-00.txt -- but backwards compatibility with > this would be the only reason to keep the client's verify_data in the > server's extension. I could certainly live with this if the TLS WG wanted to change it. I don't know how the implementors feel about it. -Ekr From ekr@networkresonance.com Sun Nov 15 15:45:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A770C3A6A44 for ; Sun, 15 Nov 2009 15:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KFkKz2x1xz9 for ; Sun, 15 Nov 2009 15:45:34 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 1452C3A6765 for ; Sun, 15 Nov 2009 15:45:33 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9obR-0004pY-00 for tls@ietf.org; Mon, 16 Nov 2009 01:33:53 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C2E8A69F83F; Mon, 16 Nov 2009 01:35:09 +0200 (EET) Date: Mon, 16 Nov 2009 01:35:09 +0200 From: Eric Rescorla To: Bodo Moeller In-Reply-To: <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115233509.C2E8A69F83F@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:45:34 -0000 At Sun, 15 Nov 2009 11:36:07 -0800, Bodo Moeller wrote: > > On Nov 12, 2009, at 10:00 PM, Eric Rescorla wrote: > > > > > The issue isn't whether the client sends it. Of course the client > > sends it. It's whether the client aborts the connection of the server > > doesn't return it. > > Why make a client send it on the initial handshake if that client > wouldn't have plans to abort the connection if the server doesn't > acknowledge it? Interoperability seems easier if you don't send it. Agreed. I've rethought this point since I wrote it. -Ekr From ekr@networkresonance.com Sun Nov 15 15:45:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F273A6A49 for ; Sun, 15 Nov 2009 15:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfc001J4BKIp for ; Sun, 15 Nov 2009 15:45:34 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 8A5BA3A6A40 for ; Sun, 15 Nov 2009 15:45:34 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9oZk-0004KW-00 for tls@ietf.org; Mon, 16 Nov 2009 01:32:08 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 88BC069F83E; Mon, 16 Nov 2009 01:33:24 +0200 (EET) Date: Mon, 16 Nov 2009 01:33:20 +0200 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B006AE1.30206@extendedsubset.com> References: <4AFF79A4.6020706@extendedsubset.com> <4B00662E.1020506@bolyard.me> <4B006AE1.30206@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115233324.88BC069F83E@kilo.networkresonance.com> Cc: "tls >> \"tls@ietf.org\"" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:45:35 -0000 At Sun, 15 Nov 2009 14:56:01 -0600, Marsh Ray wrote: > >> === R9. Must interoperate perfectly with unpatched systems. > > > > Again, what does that mean? > > Does it mean that a patched client connects without hesitation to an > > unpatched and vulnerable server, thereby falling victim to the attack? > > It means that whatever fix we propose on to the public has to work > seamlessly. My guess is that we have one shot at delivering something in > a window that ends quite soon. If the patch makes a first impression at > breaking one in ten connections, most admins will simply choose the > patch which disables all renegotiation. Once that happens, it's gone for > good, yet a lot of important systems depend on it. I'm confused: is anyone proposing a patch on the server which would break *any* connections? The only breakage I can see is that some clients will be unable to operate with old servers. This doesn't seem to have the effect you suggest at all. -Ekr From ekr@networkresonance.com Sun Nov 15 15:45:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456B43A6A50 for ; Sun, 15 Nov 2009 15:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I5gSsCceFAY for ; Sun, 15 Nov 2009 15:45:35 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 297AF3A6A48 for ; Sun, 15 Nov 2009 15:45:35 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9oWE-0003Et-00 for tls@ietf.org; Mon, 16 Nov 2009 01:28:30 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D9DB169F839; Mon, 16 Nov 2009 01:29:43 +0200 (EET) Date: Mon, 16 Nov 2009 01:29:43 +0200 From: Eric Rescorla To: Nelson B Bolyard In-Reply-To: <4B006D46.6070107@bolyard.me> References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> <4B006D46.6070107@bolyard.me> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115232943.D9DB169F839@kilo.networkresonance.com> Cc: "tls@ietf.org" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:45:36 -0000 At Sun, 15 Nov 2009 13:06:14 -0800, Nelson B Bolyard wrote: > > On 2009-11-15 03:18 PDT, Eric Rescorla wrote: > > > 1. Servers which do not wish to do renegotiation can protect themselves > > without any change to the TLS protocol or to the client. I think > > it's pretty clearly desirable to have such servers continue to > > work with downrev clients. > > Agreed. > > > 2. Any fix must cause renegotiation between upgraded and unupgraded > > agents to fail. > > Ummm, remembering that a client's initial handshake may be a server's > renegotiation, I think that requirement needs to say that > > Any fix must cause any handshake between upgraded and non-upgraded > agents to fail, when that handshake is seen as a renegotiation by > the server, whether it is seen as an initial handshake or as a > renegotiation by the client. Agreed. > > This is true whether the fix is explicitly signalled > > via an extension, explicitly signalled via a cipher suite/version, > > or unsignaled, such as by extending the finished message hash to > > incorporate earlier handshakes/incorporating previous finished > > messages into the PRF. > > > > Thus, the minimal change is not to change initial negotiations at > > all but simply to change renegotiations. This is quite possible > > with RI simply by not sending it on the initial negotiation. Of > > course, sending it on renegotiation will cause interoperation > > failure with vulnerable servers, but that's the desired outcome. > > Are there clients who really want to remain vulnerable? I'm sure there aren't, but unless I'm missing something for the foreseeable future there is no way to avoid that while still actually being compatible. The way I mentally model this is like a software vulnerability in a popular server, e.g., OpenSSL. Until the server fixes, the attacker can subvert the server and attack the client's connection and there's really no way for the client to unilaterally defend without fingerprinting the server, which is in general impractical. -Ekr From ekr@networkresonance.com Sun Nov 15 15:45:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB07F3A6A50 for ; Sun, 15 Nov 2009 15:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbwuopUnrS6x for ; Sun, 15 Nov 2009 15:45:36 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id DFDEC3A6A40 for ; Sun, 15 Nov 2009 15:45:35 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9oMq-0000nn-00 for tls@ietf.org; Mon, 16 Nov 2009 01:18:48 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id EC03069F837; Mon, 16 Nov 2009 01:20:03 +0200 (EET) Date: Mon, 16 Nov 2009 01:20:01 +0200 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911152130.nAFLUiIP022845@fs4113.wdf.sap.corp> References: <4B00662E.1020506@bolyard.me> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115232003.EC03069F837@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:45:36 -0000 At Sun, 15 Nov 2009 22:30:44 +0100 (MET), Martin Rex wrote: > If the TLS WG ships the TLS extension RI, then it will be several months > before I will be shipping anything for the client side, because I first > will need to think about solutions for the interop problems that will > arise and how to make the client-side behaviour configurable (which > requires changes to all applications). > > An extension-less Client->Server Signaling on initial handshake is > something that I would risk shipping immediately without a configuration > option, taking care about interop problems when they're reported. To be clear, this is what I am proposing. -Ekr From ekr@networkresonance.com Sun Nov 15 15:46:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951DE3A6A33 for ; Sun, 15 Nov 2009 15:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNG7WTR4BRSV for ; Sun, 15 Nov 2009 15:46:33 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 58BAE3A6765 for ; Sun, 15 Nov 2009 15:46:33 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9ond-00086C-00 for tls@ietf.org; Mon, 16 Nov 2009 01:46:29 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 5E81069F842; Mon, 16 Nov 2009 01:47:45 +0200 (EET) Date: Mon, 16 Nov 2009 01:47:44 +0200 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B008F6D.7070303@pobox.com> References: <4B008F6D.7070303@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091115234745.5E81069F842@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:46:34 -0000 At Sun, 15 Nov 2009 15:31:57 -0800, Michael D'Errico wrote: > > Whatever the solution turns out to be, I think we all agree that it needs > to address these two simple issues: > > 1) A server needs to be able to protect against MITM attacks > 2) A client needs to be able to protect against MITM attacks > > Solving #1 is trivial since a server can simply refuse to renegotiate a > connection when the client doesn't use the agreed-upon solution. > > Solving #2 is more difficult, and it breaks down into the following two > sub-issues: > > 2a) A client needs to be able to protect against attacks > when the server is patched > 2b) A client needs to be able to protect against attacks > when the server is NOT patched > > Issue 2a is again trivially accomplished by the fact that the server > is protecting the client (issue 1, since it is patched), so the > important case is 2b and ONLY 2b, i.e. patched client / unpatched > server. > > Here is an analysis of whether proposed solutions address this case 2b: > > RI with patched client / unpatched server: > > People continue to suggest that with the RI extension, a client doesn't > need to send it on its initial handshake. This is completely wrong. > A MITM attack will absolutely succeed if the server is not patched and > the client does nothing different than it always has in the past. Thus > if RI is not used by the client in its first handshake, it gets zero > protection even though it is aware of the MITM attack. And even if the > client does use the extension, it must rely on a possibly forged Server > Hello to decide whether to continue with the handshake. > > So the client has to send the extension on every handshake including > the initial handshake. This brings up all of the interoperability > problems: lack of support for extensions even in TLS, no possible way > to use extensions with SSLv3, mischief by a MITM (removing the > extension from the hello messages, simulating a server "crash" when > the extension is sent, etc.) > > This is at best "treacherous". You misunderstand what I'm saying. Yes, clients which want to ensure that they never connect to an unfixed server need to generate RI on the initial handshake. If they don't get an affirmative response, they abort the connection. However, since this will cause incompatibility with most servers for the foreseeable future, it's not practical to turn it on. > The only interoperability "problem" is when a patched client uses the new > Finished calculation when talking to an unpatched server[*] -- the handshake > will fail. This is precisely what SHOULD happen -- the client is protected > from a potential MITM attack! A client that does not want this protection > does not need to use it. Or if it is daring it can first try the new and > fall back to the old method if it's willing to risk an attack. When the > server is patched and the client is convinced to fall back due to MITM > meddling, the server will reliably know this and can notify the proper > people to investigate the attack. But this is *exactly* the same scenario as with RI. Namely, you can include it in the handshake if you want to ensure that the server is upgraded and you don't if you don't. I fail to see what the interop advantage of this scheme is. -Ekr From jsalowey@cisco.com Sun Nov 15 15:47:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CD03A6A22 for ; Sun, 15 Nov 2009 15:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 F8VxrZ+ZUc7k for ; Sun, 15 Nov 2009 15:47:11 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 65E8D3A68A6 for ; Sun, 15 Nov 2009 15:47:11 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADoiAEurR7Ht/2dsb2JhbAC8TJYahDwEgW0 X-IronPort-AV: E=Sophos;i="4.44,748,1249257600"; d="scan'208";a="49568259" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 15 Nov 2009 23:47:11 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAFNlBnQ002676; Sun, 15 Nov 2009 23:47:11 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.3959); Sun, 15 Nov 2009 15:47:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 15:47:09 -0800 Message-ID: In-Reply-To: <4B008F6D.7070303@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Protecting against a MITM Thread-Index: AcpmS7PfbMwzYF9wTiaRvqgh4ZOQiQAASJbw References: <4B008F6D.7070303@pobox.com> From: "Joseph Salowey (jsalowey)" To: "Michael D'Errico" , X-OriginalArrivalTime: 15 Nov 2009 23:47:11.0085 (UTC) FILETIME=[F31E61D0:01CA664D] Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:47:12 -0000 > RI with patched client / unpatched server: >=20 > People continue to suggest that with the RI extension, a=20 > client doesn't > need to send it on its initial handshake. This is=20 > completely wrong. > A MITM attack will absolutely succeed if the server is=20 > not patched and > the client does nothing different than it always has in=20 > the past. Thus > if RI is not used by the client in its first handshake,=20 > it gets zero > protection even though it is aware of the MITM attack. =20 > And even if the > client does use the extension, it must rely on a possibly=20 > forged Server > Hello to decide whether to continue with the handshake. >=20 > So the client has to send the extension on every=20 > handshake including > the initial handshake. This brings up all of the interoperability > problems: lack of support for extensions even in TLS, no=20 > possible way > to use extensions with SSLv3, mischief by a MITM (removing the > extension from the hello messages, simulating a server=20 > "crash" when > the extension is sent, etc.) >=20 > This is at best "treacherous". > [Joe] I disagree. If the client has a lenient policy, meaning it will connect with unpatched servers, then it doesn't need to send the extension. If the client has a strict policy then it needs to send the extension, in this case it only needs to interoperate with servers that support the extension. I'm not sure what scenario you are trying to address. =20 From nelson@bolyard.me Sun Nov 15 15:47:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865C13A6A49 for ; Sun, 15 Nov 2009 15:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.703, 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 0X6UI6lzNmJD for ; Sun, 15 Nov 2009 15:47:24 -0800 (PST) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by core3.amsl.com (Postfix) with SMTP id BBB9E3A6A46 for ; Sun, 15 Nov 2009 15:47:24 -0800 (PST) Received: (qmail 16298 invoked from network); 15 Nov 2009 23:47:23 -0000 Received: from unknown (24.5.142.42) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 15 Nov 2009 23:47:23 -0000 Message-ID: <4B009383.8090708@bolyard.me> Date: Sun, 15 Nov 2009 15:49:23 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911152323.nAFNNr9f029282@fs4113.wdf.sap.corp> In-Reply-To: <200911152323.nAFNNr9f029282@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Safe vulnerability probing of servers possible w/o extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:47:25 -0000 On 2009-11-15 15:23 PDT, Martin Rex wrote: > First of all, the idea that clients need to probe servers is a > fatally flawed idea. There is a part of the TLS protocol called > handshake which is supposed to negotiate an interoperable set > of protocol features to perform a communication. > > Clients simply want to connect to some servers and talk to them > secrely. Client do _NOT_ want to probe servers and they do not > want to maintain lists of servers and the protocol features they > support in order to be able to talk to them. > > When it happens to TLS that clients need to start doing this in order > to be able to talk to a server on first connect, then we have really > fucked up the protocol. We know that TLS can be fixed, that servers that implement hello extensions can be fixed, and that servers that are willing to implement the next version of TLS can be fixed, and that all of these can be fixed in a way that requires no probing and no whitelists. I've done it. But we keep being told that there exists a huge body of servers with which browsers work today, servers that are either still SSL 3.0 servers, or non-compliant TLS servers that do not accept client hellos bearing hello extensions, and that clients must continue to be able to interoperate with those servers without vulnerability. I am exploring how that can be accomplished, if it can be accomplished. From marsh@extendedsubset.com Sun Nov 15 15:48:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC7C3A6A48 for ; Sun, 15 Nov 2009 15:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.548, 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 NriBhnyaYAIu for ; Sun, 15 Nov 2009 15:48:17 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 3F0B43A6A44 for ; Sun, 15 Nov 2009 15:48:17 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9opM-000KDN-AL for tls@ietf.org; Sun, 15 Nov 2009 23:48:16 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5C54E667C for ; Sun, 15 Nov 2009 23:48:15 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1821PEPABTBRk7OLmqbh84Xqb0wYhS1vF4= Message-ID: <4B00933D.7080601@extendedsubset.com> Date: Sun, 15 Nov 2009 17:48:13 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls >> \"tls@ietf.org\"" References: <4AFF79A4.6020706@extendedsubset.com> <4B00662E.1020506@bolyard.me> <4B006AE1.30206@extendedsubset.com> <20091115233324.88BC069F83E@kilo.networkresonance.com> In-Reply-To: <20091115233324.88BC069F83E@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:48:18 -0000 Eric Rescorla wrote: > At Sun, 15 Nov 2009 14:56:01 -0600, > Marsh Ray wrote: >>>> === R9. Must interoperate perfectly with unpatched systems. >>> Again, what does that mean? >>> Does it mean that a patched client connects without hesitation to an >>> unpatched and vulnerable server, thereby falling victim to the attack? >> It means that whatever fix we propose on to the public has to work >> seamlessly. My guess is that we have one shot at delivering something in >> a window that ends quite soon. If the patch makes a first impression at >> breaking one in ten connections, most admins will simply choose the >> patch which disables all renegotiation. Once that happens, it's gone for >> good, yet a lot of important systems depend on it. > > I'm confused: is anyone proposing a patch on the server which would > break *any* connections? Well, yes. But, I'm not sure why it matters if the patch is made on the client or the server. A fix that doesn't address SSLv3 gives many users and admins a choice between being vulnerable or "breaking the connection". Apparently some servers "break" when they see a hello extension. > The only breakage I can see is that some > clients will be unable to operate with old servers. This doesn't > seem to have the effect you suggest at all. Any proposed fix in which "some clients will be unable to operate with old servers" is DOA at most sites because there is a painless alternative which does not (disabling all renegotiation). - Marsh From mike-list@pobox.com Sun Nov 15 16:02:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E193A688E for ; Sun, 15 Nov 2009 16:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 7nPamjtKf+ox for ; Sun, 15 Nov 2009 16:02:10 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id A126D3A6765 for ; Sun, 15 Nov 2009 16:02:09 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 83B279EDD7 for ; Sun, 15 Nov 2009 19:02:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=IOZaJf8JJxaR xt4PXyYBHJ00h1A=; b=AMI0v5re8HLZ7O7BAHr9qNweksxbl8C73IPl6G/KPDkX eMCBBnC24WVPyXt4AgAOcXLHW8vGIaDpsRp/7A7fAUQRcAX6wCd9kVjNT3oEH6FO wKvYkRGDKNadLAYzE7sz278/fk0/TE/mBdcpSADUbbI2VM2cfhV+/t7VoA47INQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=FZR4mv 8DuVUx/KNnYDPxH0FaKUjbanFA42GWqTIdKZGFLCESdidOu/mURaKwKJpaOedbri hvv046HmdS9y1yorKgKY58FAbTxIMyoWcXPo1ciDLDpBdJAlzbbTeDm1/Dxlcd9E hCAICoWV934d6JLwrTfrXvn3aPuXLFAJnfGLk= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 804629EDD6 for ; Sun, 15 Nov 2009 19:02:08 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 1A4A59EDD4 for ; Sun, 15 Nov 2009 19:02:07 -0500 (EST) Message-ID: <4B0096BA.3030602@pobox.com> Date: Sun, 15 Nov 2009 16:03:06 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B008F6D.7070303@pobox.com> <20091115234745.5E81069F842@kilo.networkresonance.com> In-Reply-To: <20091115234745.5E81069F842@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 48451332-D243-11DE-883F-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:02:11 -0000 > I fail to see what the interop advantage of this scheme is. 1) Works with all versions of the protocol including SSLv3 2) Does not require TLS extensions 3) In fact no change to bits on the wire 4) Provides proof of an attempted MITM attack at the server Are none of these important? Mike From ekr@networkresonance.com Sun Nov 15 16:08:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74173A6832 for ; Sun, 15 Nov 2009 16:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW0zeolvYN-m for ; Sun, 15 Nov 2009 16:08:04 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 0C1F23A6765 for ; Sun, 15 Nov 2009 16:08:03 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9p8S-0005Qv-00 for tls@ietf.org; Mon, 16 Nov 2009 02:08:00 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D8DAB69F845; Mon, 16 Nov 2009 02:09:16 +0200 (EET) Date: Mon, 16 Nov 2009 02:09:16 +0200 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B00933D.7080601@extendedsubset.com> References: <4AFF79A4.6020706@extendedsubset.com> <4B00662E.1020506@bolyard.me> <4B006AE1.30206@extendedsubset.com> <20091115233324.88BC069F83E@kilo.networkresonance.com> <4B00933D.7080601@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116000916.D8DAB69F845@kilo.networkresonance.com> Cc: "tls >> \"tls@ietf.org\"" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:08:04 -0000 At Sun, 15 Nov 2009 17:48:13 -0600, Marsh Ray wrote: > > Eric Rescorla wrote: > > At Sun, 15 Nov 2009 14:56:01 -0600, > > Marsh Ray wrote: > >>>> === R9. Must interoperate perfectly with unpatched systems. > >>> Again, what does that mean? > >>> Does it mean that a patched client connects without hesitation to an > >>> unpatched and vulnerable server, thereby falling victim to the attack? > >> It means that whatever fix we propose on to the public has to work > >> seamlessly. My guess is that we have one shot at delivering something in > >> a window that ends quite soon. If the patch makes a first impression at > >> breaking one in ten connections, most admins will simply choose the > >> patch which disables all renegotiation. Once that happens, it's gone for > >> good, yet a lot of important systems depend on it. > > > > I'm confused: is anyone proposing a patch on the server which would > > break *any* connections? > > Well, yes. Really? Which fix has this property? Every single fix I have seen proposed can be safely applied to any server (though of course they necessarily have the property of breaking renegotiation with old clients, but that's the intended behavior.) > But, I'm not sure why it matters if the patch is made on the > client or the server. Because you keep talking about "sites" but in most sites the server operator gets to control just that, the server, and more or less takes their clients as they find them. The server operator's choice has far more to do with the tradeoff between having insecure renegotiation or secure renegotiation but broken compatibility with the vast pool of unpatched clients. AFAICT the only setting in which that decision is at all affected by our choice of approach is if one side is running SSLv3 *and* the maintainer of the SSLv3 stack would apply one fix but not another. What actively maintained stack is SSLv3 only? -Ekr From mrex@sap.com Sun Nov 15 16:10:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F15A3A6832 for ; Sun, 15 Nov 2009 16:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[AWL=0.621, 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 nHg7HdYhJ1sW for ; Sun, 15 Nov 2009 16:10:30 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 282033A6A42 for ; Sun, 15 Nov 2009 16:10:29 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAG0APsQ026067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 01:10:25 +0100 (MET) From: Martin Rex Message-Id: <200911160010.nAG0AP0f001956@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 16 Nov 2009 01:10:25 +0100 (MET) In-Reply-To: <20091115233509.C2E8A69F83F@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 01:35:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:10:31 -0000 Eric Rescorla wrote: > > Bodo Moeller wrote: > > > > Why make a client send it on the initial handshake if that client > > wouldn't have plans to abort the connection if the server doesn't > > acknowledge it? Interoperability seems easier if you don't send it. > > Agreed. I've rethought this point since I wrote it. I see value in extension-less signaling on initial handshake, because it will immediately provide protection to updated clients when the server is updated even when both, client and server still support the insecure renegotiation (i.e. very early in the transition period) or the client still allowys a reconnect fallback with an extension-less ClientHello. -Martin From mike-list@pobox.com Sun Nov 15 16:14:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831233A6783 for ; Sun, 15 Nov 2009 16:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 7SoYWpGXN7hN for ; Sun, 15 Nov 2009 16:13:59 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 8EC4F3A6A22 for ; Sun, 15 Nov 2009 16:13:59 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 242A69EEA7 for ; Sun, 15 Nov 2009 19:13:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=mrdeQVBtGPZf cOWdS5zl0ksz/ts=; b=n2a4jX+vZOKx1alT5sq61XkBt02FME3FeZz9/aqGDMBp 63oZXvzSiIhavL9l/+vJy1L2rRDI7SwAlF+g8mmq0C/z7psJrMCPRPQGYj7ZrfjY vn8bSokj96D+V7GI6CDWQ0M32xXxtZeuVqAok3g2qsjY0jKZWAlVtj6T4U2hEwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ToDIAO Tkg8DEsBl6iIkaQ7qZc38QenZnBdtbfZEyr5vIccnkbnZ7REvHXZT0f2/q9HtkIT 03uEy+NbWUB4TT4aYFn28xUyO2VBu4RrwJP96mZA/5NqYVXlTMiEcgMiQ8pTZVEF O+vYkm6nCv++U3u38hcMQj+4sUURlUqTPctlA= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 21E379EEA6 for ; Sun, 15 Nov 2009 19:13:59 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id B4AC69EEA3 for ; Sun, 15 Nov 2009 19:13:57 -0500 (EST) Message-ID: <4B009980.2040209@pobox.com> Date: Sun, 15 Nov 2009 16:14:56 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B008F6D.7070303@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: EFD3DA1A-D244-11DE-93BA-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:14:00 -0000 >> RI with patched client / unpatched server: >> >> People continue to suggest that with the RI extension, a >> client doesn't >> need to send it on its initial handshake. This is >> completely wrong. >> A MITM attack will absolutely succeed if the server is >> not patched and >> the client does nothing different than it always has in >> the past. Thus >> if RI is not used by the client in its first handshake, >> it gets zero >> protection even though it is aware of the MITM attack. >> And even if the >> client does use the extension, it must rely on a possibly >> forged Server >> Hello to decide whether to continue with the handshake. >> >> So the client has to send the extension on every >> handshake including >> the initial handshake. This brings up all of the interoperability >> problems: lack of support for extensions even in TLS, no >> possible way >> to use extensions with SSLv3, mischief by a MITM (removing the >> extension from the hello messages, simulating a server >> "crash" when >> the extension is sent, etc.) >> >> This is at best "treacherous". >> > [Joe] I disagree. If the client has a lenient policy, meaning it will > connect with unpatched servers, then it doesn't need to send the > extension. If the client has a strict policy then it needs to send the > extension, in this case it only needs to interoperate with servers that > support the extension. I'm not sure what scenario you are trying to > address. But there are lots of problems with "it needs to send the extension." Won't work for SSLv3. Some TLS-capable servers even choke on them. A MITM can simulate this problem for servers that DO support extensions, possibly causing insecure fallback strategies to take place. Mike From ekr@networkresonance.com Sun Nov 15 16:16:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB293A68A6 for ; Sun, 15 Nov 2009 16:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G8mJ1svfpq2 for ; Sun, 15 Nov 2009 16:16:58 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 8A7943A6783 for ; Sun, 15 Nov 2009 16:16:57 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9pH5-0007qU-00 for tls@ietf.org; Mon, 16 Nov 2009 02:16:55 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 0A5FF69F856; Mon, 16 Nov 2009 02:18:11 +0200 (EET) Date: Mon, 16 Nov 2009 02:18:10 +0200 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B009980.2040209@pobox.com> References: <4B008F6D.7070303@pobox.com> <4B009980.2040209@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116001812.0A5FF69F856@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:16:58 -0000 At Sun, 15 Nov 2009 16:14:56 -0800, Michael D'Errico wrote: > > >> RI with patched client / unpatched server: > >> > >> People continue to suggest that with the RI extension, a > >> client doesn't > >> need to send it on its initial handshake. This is > >> completely wrong. > >> A MITM attack will absolutely succeed if the server is > >> not patched and > >> the client does nothing different than it always has in > >> the past. Thus > >> if RI is not used by the client in its first handshake, > >> it gets zero > >> protection even though it is aware of the MITM attack. > >> And even if the > >> client does use the extension, it must rely on a possibly > >> forged Server > >> Hello to decide whether to continue with the handshake. > >> > >> So the client has to send the extension on every > >> handshake including > >> the initial handshake. This brings up all of the interoperability > >> problems: lack of support for extensions even in TLS, no > >> possible way > >> to use extensions with SSLv3, mischief by a MITM (removing the > >> extension from the hello messages, simulating a server > >> "crash" when > >> the extension is sent, etc.) > >> > >> This is at best "treacherous". > >> > > [Joe] I disagree. If the client has a lenient policy, meaning it will > > connect with unpatched servers, then it doesn't need to send the > > extension. If the client has a strict policy then it needs to send the > > extension, in this case it only needs to interoperate with servers that > > support the extension. I'm not sure what scenario you are trying to > > address. > > But there are lots of problems with "it needs to send the extension." > Won't work for SSLv3. Some TLS-capable servers even choke on them. All of which servers are presumptively vulnerable. Any server which applies any of these fixes can clearly add support for extensions trivially. > A MITM can simulate this problem for servers that DO support extensions, > possibly causing insecure fallback strategies to take place. As I noted earlier, this is easily fixed with a fake cipher suite. -Ekr From ekr@networkresonance.com Sun Nov 15 16:22:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D0B3A6A22 for ; Sun, 15 Nov 2009 16:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.054 X-Spam-Level: * X-Spam-Status: No, score=1.054 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU2nuSvuKJ93 for ; Sun, 15 Nov 2009 16:22:39 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 3A90C3A67D8 for ; Sun, 15 Nov 2009 16:22:39 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9pMc-0000sL-00 for tls@ietf.org; Mon, 16 Nov 2009 02:22:38 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 6EEC269F857 for ; Mon, 16 Nov 2009 02:23:54 +0200 (EET) Date: Mon, 16 Nov 2009 02:23:53 +0200 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116002354.6EEC269F857@kilo.networkresonance.com> Subject: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:22:40 -0000 I know there has been a bunch of discussion about the prevalance of SSLv3-only stacks. As one data point, Lee, Malkin, and Nahum's 2007 IMC paper (http://www.imconf.net/imc-2007/papers/imc130.pdf) indicates 98+% deployment of TLS on Web servers. -Ekr From marsh@extendedsubset.com Sun Nov 15 16:29:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605703A67D8 for ; Sun, 15 Nov 2009 16:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 KHgnMqRDl6Y2 for ; Sun, 15 Nov 2009 16:29:48 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 96FA63A676A for ; Sun, 15 Nov 2009 16:29:48 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9pTX-00032N-LE for tls@ietf.org; Mon, 16 Nov 2009 00:29:47 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7751A667C for ; Mon, 16 Nov 2009 00:29:46 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+6YAYU7vorjdMRpkkcxfLduQC+mXx67sg= Message-ID: <4B009CF8.800@extendedsubset.com> Date: Sun, 15 Nov 2009 18:29:44 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: tls@ietf.org References: <4B008F6D.7070303@pobox.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:29:49 -0000 Joseph Salowey (jsalowey) wrote: > [Joe] I disagree. If the client has a lenient policy, meaning it will > connect with unpatched servers, then it doesn't need to send the > extension. If the client has a strict policy then it needs to send the > extension, in this case it only needs to interoperate with servers that > support the extension. I'm not sure what scenario you are trying to > address. Well, for example, the server doesn't want to accept vulnerable connections from unpatched clients. Some attacks are possible even if the server does not renegotiate. This plan of making the client signaling contingent on the client's willingness to renegotiate seems suspicious to me. It raises a few questions: How often do SSL/TLS clients actually refuse renegotiation at the request of a patched server? Do we really want a situation where a patched client is talking to a patched server, yet neither of them know it? If an extension is really the solution, why wouldn't the client send one every time? How does it help to make it conditional? Does thus segment the protocol into "client will renegotiate" and "client won't renegotiate" versions? Does the client have to decide that in advance? If the client does send the extension does that imply he will in fact be willing to renegotiate later? If not, how will developers test that odd case? Does this effectively add a new flag to the TLS library API so the app code can indicate its willingness to renegotiate? Can the client change his mind later? Assuming most TLS library APIs and apps using them don't change immediately to use it, it will only be a small percentage of fixed clients exercising their right not to send the extension. Do we really want to add another under-used, under-tested corner case to the protocol? Do we want network monitoring, IDS, firewall, and other TLS implementors to have to consider this odd case? Doesn't this case prevent them from warning about unsafe clients on the network? - Marsh From mrex@sap.com Sun Nov 15 16:37:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C5D3A67D8 for ; Sun, 15 Nov 2009 16:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.552, 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 valz0OIZdzda for ; Sun, 15 Nov 2009 16:37:33 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0C6563A676A for ; Sun, 15 Nov 2009 16:37:32 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAG0bVXB015250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Nov 2009 01:37:31 +0100 (MET) From: Martin Rex Message-Id: <200911160036.nAG0atRS014903@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Mon, 16 Nov 2009 01:36:55 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal04 X-SAP: out Subject: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:37:34 -0000 The most simplistic approch to renego protection is 1. the client signals that it is patched through a fake ciphersuite ID in each ClientHello 2. the client only supports secure renegotiation and secure renegotiation is specified to change the definition of the handshake message hash for renegotiation handshakes to include the verify_data of the client.finished and server.finished after the ServerHello. Everything else is options for vendors and users. If we do not provide a standardized signaling Server->Client in the client hello, then it is not possible for the clients to offer the option for insecure renegotiation (I have no idea whether such a desire exists, but it might easily exist during transition). With this simplistic approach, an MITM can not proxy a clients initial handshake into an updated servers renegotiation, even when the server still allows insecure renegotiation (e.g. during the transition period). I really like to hear convincing arguments why we need the TLS extension in the renegotiation handshake, and why changing the definition for the handshake message hash instead is not a superior alternative. In particular one that will grow naturally into future TLS revisions. -Martin From mrex@sap.com Sun Nov 15 16:48:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30C23A68E6 for ; Sun, 15 Nov 2009 16:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.545 X-Spam-Level: X-Spam-Status: No, score=-4.545 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_40=-0.185, 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 VqsaivLVMlyz for ; Sun, 15 Nov 2009 16:48:42 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A41D43A67EC for ; Sun, 15 Nov 2009 16:48:41 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAG0md69026647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 01:48:39 +0100 (MET) From: Martin Rex Message-Id: <200911160048.nAG0mPEP015280@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 16 Nov 2009 01:48:25 +0100 (MET) In-Reply-To: <20091116002354.6EEC269F857@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 02:23:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:48:42 -0000 Eric Rescorla wrote: > > I know there has been a bunch of discussion about the prevalance of > SSLv3-only stacks. As one data point, Lee, Malkin, and Nahum's 2007 > IMC paper (http://www.imconf.net/imc-2007/papers/imc130.pdf) indicates > 98+% deployment of TLS on Web servers. So? Servers are in much safer position to support newer TLS protocol versions, because they get to choose. I'm complaining on the problem we might be creating for the clients, those Servers which _are_ going to be fixed, can implement whatever solution we come up with (provided the client signals through ClientHello). Clients bear the burden to make safe assumptions about what is going to be interoperable with the server, and safe protocol features are the reason why the amount of traffic on the internet that is still using prtocol version 0x03,0x00 (aka SSLv3) is _MUCH_ larger as the amount of public Web Servers that supports TLS. MS IIS6 on WinXP pro 64-bit likely supports TLS 1.0 by default. MSIE6 on WinXP pro 64-bit offers only SSLv3 by default. What this statistics likely does not cover is Intranet Servers that offer TLS. Some of these run vital applications for companies. -Martin From marsh@extendedsubset.com Sun Nov 15 16:54:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9B93A68A5 for ; Sun, 15 Nov 2009 16:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 8biiwIyoWgbZ for ; Sun, 15 Nov 2009 16:54:13 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 2F7933A68A8 for ; Sun, 15 Nov 2009 16:54:13 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1N9prA-0007f5-7t; Mon, 16 Nov 2009 00:54:12 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 70173667C; Mon, 16 Nov 2009 00:54:10 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18QinLGs8Y0Xh74vjhCVQpkzRtea59WV3I= Message-ID: <4B00A2B0.70804@extendedsubset.com> Date: Sun, 15 Nov 2009 18:54:08 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911160048.nAG0mPEP015280@fs4113.wdf.sap.corp> In-Reply-To: <200911160048.nAG0mPEP015280@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 00:54:13 -0000 Martin Rex wrote: > > What this statistics likely does not cover is Intranet Servers > that offer TLS. Some of these run vital applications for companies. It bears repeating that SSL/TLS is much much more than https. What worries me are deployments like [all the parking meters and traffic lights in ]. Or look at all the little plastic boxes returned from searches like this: http://search.hp.com/query.html?qt=ssl/tls - Marsh From mike-list@pobox.com Sun Nov 15 17:12:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F943A6831 for ; Sun, 15 Nov 2009 17:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 l4yIF2cGWW9n for ; Sun, 15 Nov 2009 17:12:11 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 082B33A67FC for ; Sun, 15 Nov 2009 17:12:09 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 45C7D9E29B for ; Sun, 15 Nov 2009 20:12:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=1jgRhzHMc+wX fXEfhyft+LQVM8k=; b=Bw8El7/rskowoXW8b8f6kPY6i9cH2eMNibfBLosax/Ck h1/9NSP8dDKLSEOghFj7SlG5/sfg4Dt1rGlCLLXTaGAFoqRs9XS8HFifcdkYi3rq 34g3oRvjniMZjRsNQbXA+R4k+TB6iAb27nP6vk1+VpdL5UoY5q8qO3PIEV0qNmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=w+rAj1 plFiFIR0gXEultKZa9CQOEKbTNTdWCLGas61cVnZOei16Ii8GpdNX5upo31RAi31 Rk10py66kL8Py7oq4jK0Vyt6/A3vvvdRBzI/jFk1dqyiQUorkmX5bTOyL5zXHlyD YAFnltKFxa9vZZwNui7dswvrEw7Yxxm83HsJw= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 422CA9E29A for ; Sun, 15 Nov 2009 20:12:08 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id D4DA99E298 for ; Sun, 15 Nov 2009 20:12:07 -0500 (EST) Message-ID: <4B00A722.1020400@pobox.com> Date: Sun, 15 Nov 2009 17:13:06 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911160036.nAG0atRS014903@fs4113.wdf.sap.corp> In-Reply-To: <200911160036.nAG0atRS014903@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 0F8378E0-D24D-11DE-84F6-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 01:12:12 -0000 > The most simplistic approch to renego protection is > > 1. the client signals that it is patched through a fake > ciphersuite ID in each ClientHello > > 2. the client only supports secure renegotiation and > secure renegotiation is specified to change the definition > of the handshake message hash for renegotiation handshakes > to include the verify_data of the client.finished and > server.finished after the ServerHello. No, this does not plug the hole. The magic ciphersuite in (1) requires that the server recognize it, i.e. it is patched. Therefore it will not perform insecure renegotiation even without seeing the ciphersuite (especially without seeing it). And again the client's INITIAL handshake is the one that the server sees as a renegotiation in Marsh's attack, so the fact that the client won't REnegotiate (2) is unhelpful; the attack has already completed. Mike From mike-list@pobox.com Sun Nov 15 17:36:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9742E3A6A60 for ; Sun, 15 Nov 2009 17:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 vK0yKZt2OXQ6 for ; Sun, 15 Nov 2009 17:36:04 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id AB3F13A6A4D for ; Sun, 15 Nov 2009 17:36:04 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 10E789E46D for ; Sun, 15 Nov 2009 20:36:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=YS74GHZ5g8+D DJRHSlHYL6uFsIg=; b=ECzByJjjpyW2ZjVVYwdOsPFWIOpyC1PYLeag7uAcfZA9 x1Ta0N5f02SQLaydQJZmaHGhb50Ui7EMGHumpqYHkQTi9ijTCTco5fS/fAf5uuTm isfqgQuedrR/CN5BW9Jd4g8Lk6l5pJMFvJz9oSpZXnYqXmCQy3gx88kXa88dm/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=TeproV OgKsTVnjB7uemXeIpuOCjbbnV/zaaCtfUq9W2mypUTqA6Q0dEvGZ692g80a+oHOw 9VP+Oy44BoCUO7s7K/Y4WsiTSvz5qXGN/vPduBLoHLir2t/rvdL8Ie68IKQIlEx5 I+jraj9ed7YP3RKejP8/Nahdih8rfdo1u5xn4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0E18E9E46C for ; Sun, 15 Nov 2009 20:36:01 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id B6D9B9E46B for ; Sun, 15 Nov 2009 20:36:00 -0500 (EST) Message-ID: <4B00ACBB.6060805@pobox.com> Date: Sun, 15 Nov 2009 17:36:59 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AFF79A4.6020706@extendedsubset.com> In-Reply-To: <4AFF79A4.6020706@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 65858A50-D250-11DE-A9BF-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 01:36:05 -0000 > === R4. Must indicate presence of patch in plaintext. > > Intrusion detection, network auditing, and firewall tools will benefit > from seeing that the fix is applied in the unencrypted part of the > initial handshake. > > For most sites, this is perhaps the only advantage the patch has over > disabling renegotiation. Without it, many minimally-inspecting firewalls > will be configured to simply drop all renegotiations. I disagree that this is a definite requirement. In my proposal there are NO changes to the bits on the wire. Therefore it is impossible for a MITM to mess with the handshake in any way that it can not already. I believe that this is a worthy goal. Adding extensions or magic ciphersuites are all possible new points of attack for the MITM. Changing the Finished message calculation even for initial handshakes allows clients and servers both to complete the handshake without worry of being attacked. A failure would imply either: - a patched client connected to an unpatched server - the server is patched but a MITM was causing trouble I believe these are precisely the two failures we want by default. With the RI extension, a client that wants to protect itself from an unpatched server needs to abort the handshake before sending its Finished message. This is the key -- neither side will know for certain that an attack took place since Finished messages are not exchanged, and can't be if you want to remove the possibility of an attack. Mike From djhopwood@googlemail.com Sun Nov 15 17:42:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2D23A68CC for ; Sun, 15 Nov 2009 17:42:43 -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 s20XUE-lFjOL for ; Sun, 15 Nov 2009 17:42:42 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 23EAA3A62C1 for ; Sun, 15 Nov 2009 17:42:41 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1812470eyd.51 for ; Sun, 15 Nov 2009 17:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=mVQfhfy5N4CcEUyJYwF9IzngonfZ6M7boKNB3NGnf0E=; b=TgkC8nRTch/JEGVmwR86xoxxmzauQJ1Uq9RqPVsIT+36ydNi7mBA0m4JqjYjyYfBc4 wV+X3V/dr4aSaMWiRN9rQvHqDKyO3EQV/vUlTcOqL3ThJ6Nqzw9tT82kNJ1tOQ2MDlLm HgAbbLH9myasDDJTjlEInYSxVhh9D6LOlT728= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=rfkk5vAaGYJ+iW0687fGe6pxeKZ9Ep00QKXukpQBEadvysQLwaIg24TN03X1rUpUHD c4D2r9ZKz6kB3ap9uOehC4UOV23FaUFmPUrolCNYfWNwld72w4YFClx44aYkEPIZi6n8 YlPdOl+NFZzT+r0+BxSiUQxRd4422V3Ji9odI= Received: by 10.213.110.137 with SMTP id n9mr4253432ebp.75.1258335755459; Sun, 15 Nov 2009 17:42:35 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 28sm398412eyg.46.2009.11.15.17.42.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Nov 2009 17:42:35 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B00AE09.8050906@jacaranda.org> Date: Mon, 16 Nov 2009 01:42:33 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B008F6D.7070303@pobox.com> In-Reply-To: <4B008F6D.7070303@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1946F1CD4D84ECFDA1238321" Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 01:42:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1946F1CD4D84ECFDA1238321 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > Whatever the solution turns out to be, I think we all agree that it nee= ds > to address these two simple issues: >=20 > 1) A server needs to be able to protect against MITM attacks > 2) A client needs to be able to protect against MITM attacks >=20 > Solving #1 is trivial since a server can simply refuse to renegotiat= e a > connection when the client doesn't use the agreed-upon solution. >=20 > Solving #2 is more difficult, and it breaks down into the following = two > sub-issues: >=20 > 2a) A client needs to be able to protect against attacks > when the server is patched > 2b) A client needs to be able to protect against attacks > when the server is NOT patched >=20 > Issue 2a is again trivially accomplished by the fact that the server= > is protecting the client (issue 1, since it is patched), so the > important case is 2b and ONLY 2b, i.e. patched client / unpatched > server. >=20 > Here is an analysis of whether proposed solutions address this case 2b:= >=20 > RI with patched client / unpatched server: >=20 > People continue to suggest that with the RI extension, a client does= n't > need to send it on its initial handshake. This is completely wrong.= It is not "completely wrong". For a patched client, not sending a signal on the initial handshake (regardless of the form of that signal) matters if-and-only-if the client is going to refuse to interoperate with unpatched servers. If a client would continue with an initial connection to a server that it= knows is unpatched, then the attack is unavoidable in that case. That is true for *any* possible solution, not just RI. > A MITM attack will absolutely succeed if the server is not patched a= nd > the client does nothing different than it always has in the past. T= hus > if RI is not used by the client in its first handshake, it gets zero= > protection even though it is aware of the MITM attack. And even if = the > client does use the extension, it must rely on a possibly forged Ser= ver > Hello to decide whether to continue with the handshake. >=20 > So the client has to send the extension on every handshake including= > the initial handshake. This brings up all of the interoperability > problems: lack of support for extensions even in TLS, no possible wa= y > to use extensions with SSLv3, mischief by a MITM (removing the > extension from the hello messages, simulating a server "crash" when > the extension is sent, etc.) These kinds of "mischief by a MITM" won't work. The Finished hashes will fail to verify, and the attacker gains no advantage: - if the client policy is to connect to unpatched servers, then the "mischief" wasn't needed; the vulnerability is unavoidable. - if the client policy is not to connect to unpatched servers, then it MUST NOT fall back to a handshake that doesn't send the extension -- but it doesn't need any such fallback, because all patched servers can be assumed TLS- and extension-tolerant. (If a server accepts the extension but remains TLS- and extension-toleran= t, then that's simply a broken implementation of the patch, which should be revealed immediately in interoperability testing with patched clients configured to use the stricter policy.) The RI proposal does have some disadvantages (I'll discuss those separately), but it doesn't have the disadvantages you state here. > Modifying the Finished message calculation: >=20 > If instead of RI we change the Finished message calculation, it need= s > to protect patched clients that connect to unpatched servers (the on= ly > case that matters -- see above). If the Finished message calculatio= n > were to remain the same on initial handshakes, then again the client= > gets absolutely no protection when connecting to an unpatched server= > since it will use the old unchanged calculation even on renegotiatio= ns. >=20 > Here is my proposal for a backward-compatible solution that also protec= ts > the important case 2b above: >=20 > This solution is to make available a modified Finished calculation that= a > patched client can use for all handshakes including the initial one. T= his > solution does not even break compatibility with old clients -- a server= > would support BOTH the old and the new Finished message computation and= do > the right thing based on which one was used by the client. This has a significant disadvantage relative to the RI proposal: Consider a patched client that wants to connect to unpatched servers. With your suggested approach, such a client must use the old Finished message computation on an initial handshake (or else it must add a fallba= ck in order to connect to those servers, which is undesirable). Therefore, i= t isn't distinguishable from an unpatched client by looking at cleartext handshake messages. My proposal of changing the Finished hash computation for renegotiations only, plus sending an empty extension to signal patched status, does not have this disadvantage. It also does not rely on the extension for anything other than detection of patched/unpatched status. > The only interoperability "problem" is when a patched client uses the n= ew > Finished calculation when talking to an unpatched server[*] -- the > handshake will fail. This is precisely what SHOULD happen -- the clien= t > is protected from a potential MITM attack! It is quite unrealistic to suppose that *all* client implementors will want to refuse to interoperate with unpatched servers. That has to be an option, not a requirement or assumption. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig1946F1CD4D84ECFDA1238321 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksArgkACgkQWUc8YzyzqAf/LwEAl/SB9tks/BcbDCnp94KN+OOb +QF8WTtLKaBkq8xTXGQA/3NDl1j3PNGNN6VHQnAg6aoZlxyUhPPfvq1FibghzKWQ =dG+g -----END PGP SIGNATURE----- --------------enig1946F1CD4D84ECFDA1238321-- From jsalowey@cisco.com Sun Nov 15 18:39:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10BB3A68EE for ; Sun, 15 Nov 2009 18:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 zLVO4YoobtK2 for ; Sun, 15 Nov 2009 18:39:12 -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 DB2B53A6807 for ; Sun, 15 Nov 2009 18:39:12 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIpKAEurR7H+/2dsb2JhbAC9MJYThDwEgW0 X-IronPort-AV: E=Sophos;i="4.44,748,1249257600"; d="scan'208";a="433323229" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Nov 2009 02:39:12 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAG2dCPL012245; Mon, 16 Nov 2009 02:39:12 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.3959); Sun, 15 Nov 2009 18:39:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 18:39:10 -0800 Message-ID: In-Reply-To: <4B009980.2040209@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Protecting against a MITM Thread-Index: AcpmUbQmvb6FuUTlTRS0H8EhzAJMvwAE334w References: <4B008F6D.7070303@pobox.com> <4B009980.2040209@pobox.com> From: "Joseph Salowey (jsalowey)" To: "Michael D'Errico" , X-OriginalArrivalTime: 16 Nov 2009 02:39:12.0419 (UTC) FILETIME=[FB1CF730:01CA6665] Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 02:39:13 -0000 =20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Michael D'Errico > Sent: Sunday, November 15, 2009 4:15 PM > To: tls@ietf.org > Subject: Re: [TLS] Protecting against a MITM >=20 > >> RI with patched client / unpatched server: > >> > >> People continue to suggest that with the RI extension,=20 > a client=20 > >> doesn't > >> need to send it on its initial handshake. This is completely=20 > >> wrong. > >> A MITM attack will absolutely succeed if the server is not=20 > >> patched and > >> the client does nothing different than it always has=20 > in the past. =20 > >> Thus > >> if RI is not used by the client in its first=20 > handshake, it gets=20 > >> zero > >> protection even though it is aware of the MITM attack. =20 > >> And even if the > >> client does use the extension, it must rely on a=20 > possibly forged=20 > >> Server > >> Hello to decide whether to continue with the handshake. > >> > >> So the client has to send the extension on every handshake=20 > >> including > >> the initial handshake. This brings up all of the=20 > interoperability > >> problems: lack of support for extensions even in TLS,=20 > no possible=20 > >> way > >> to use extensions with SSLv3, mischief by a MITM (removing the > >> extension from the hello messages, simulating a server "crash"=20 > >> when > >> the extension is sent, etc.) > >> > >> This is at best "treacherous". > >> > > [Joe] I disagree. If the client has a lenient policy,=20 > meaning it will=20 > > connect with unpatched servers, then it doesn't need to send the=20 > > extension. If the client has a strict policy then it needs to send=20 > > the extension, in this case it only needs to interoperate=20 > with servers=20 > > that support the extension. I'm not sure what scenario you=20 > are trying=20 > > to address. >=20 > But there are lots of problems with "it needs to send the extension." [Joe] I haven't been convinced of this. =20 > Won't work for SSLv3. =20 [Joe] Why not? You will need to apply some patch to SSLv3, any of them will be incompatible with.=20 >Some TLS-capable servers even choke on them. [Joe] Perhaps, but they won't be patched TLS servers. The extension is sent in the initial handshake when the client is implementing a strict policy. In this case you do not want to talk to broken servers. > A MITM can simulate this problem for servers that DO support=20 > extensions, possibly causing insecure fallback strategies to=20 > take place. >=20 [Joe] A strict policy would not fallback. =20 > Mike > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From jsalowey@cisco.com Sun Nov 15 18:56:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1787F3A6814 for ; Sun, 15 Nov 2009 18:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 SXIHCKS1P37C for ; Sun, 15 Nov 2009 18:56:10 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2BFCA3A67D1 for ; Sun, 15 Nov 2009 18:56:10 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABlOAEurRN+J/2dsb2JhbAC9MJYUgj+BfQQ X-IronPort-AV: E=Sophos;i="4.44,748,1249257600"; d="scan'208";a="104337443" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2009 02:56:08 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAG2u8Ya029902; Mon, 16 Nov 2009 02:56:08 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.3959); Sun, 15 Nov 2009 18:56:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 18:56:05 -0800 Message-ID: In-Reply-To: <4B009CF8.800@extendedsubset.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Protecting against a MITM Thread-Index: AcpmU+0GANFwVlTkR7OhdIVgh1S/twAE52Hw References: <4B008F6D.7070303@pobox.com> <4B009CF8.800@extendedsubset.com> From: "Joseph Salowey (jsalowey)" To: "Marsh Ray" X-OriginalArrivalTime: 16 Nov 2009 02:56:07.0276 (UTC) FILETIME=[5803DAC0:01CA6668] Cc: tls@ietf.org Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 02:56:11 -0000 =20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Marsh Ray > Sent: Sunday, November 15, 2009 4:30 PM > Cc: tls@ietf.org > Subject: Re: [TLS] Protecting against a MITM >=20 > Joseph Salowey (jsalowey) wrote: > > [Joe] I disagree. If the client has a lenient policy,=20 > meaning it will=20 > > connect with unpatched servers, then it doesn't need to send the=20 > > extension. If the client has a strict policy then it needs to send=20 > > the extension, in this case it only needs to interoperate=20 > with servers=20 > > that support the extension. I'm not sure what scenario you=20 > are trying=20 > > to address. >=20 > Well, for example, the server doesn't want to accept=20 > vulnerable connections from unpatched clients. Some attacks=20 > are possible even if the server does not renegotiate. >=20 > This plan of making the client signaling contingent on the=20 > client's willingness to renegotiate seems suspicious to me.=20 [Joe] Perhaps I mis-spoke on another thread. A strict policy does not allow connection to unpatched servers. A lenient policy allows connection to unpatched servers. These policies don't have to do with whether the client wants to renegotiate, but rather whether they require the server to do secure renegotiation. =20 > It raises a few > questions: >=20 > How often do SSL/TLS clients actually refuse renegotiation at=20 > the request of a patched server? >=20 > Do we really want a situation where a patched client is=20 > talking to a patched server, yet neither of them know it? >=20 > If an extension is really the solution, why wouldn't the=20 > client send one every time? How does it help to make it conditional? >=20 > Does thus segment the protocol into "client will renegotiate"=20 > and "client won't renegotiate" versions? Does the client have=20 > to decide that in advance? >=20 > If the client does send the extension does that imply he will=20 > in fact be willing to renegotiate later? If not, how will=20 > developers test that odd case? >=20 > Does this effectively add a new flag to the TLS library API=20 > so the app code can indicate its willingness to renegotiate?=20 > Can the client change his mind later? >=20 > Assuming most TLS library APIs and apps using them don't=20 > change immediately to use it, it will only be a small=20 > percentage of fixed clients exercising their right not to=20 > send the extension. Do we really want to add another=20 > under-used, under-tested corner case to the protocol? >=20 > Do we want network monitoring, IDS, firewall, and other TLS=20 > implementors to have to consider this odd case? Doesn't this=20 > case prevent them from warning about unsafe clients on the network? >=20 > - Marsh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From djhopwood@googlemail.com Sun Nov 15 19:09:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DC33A6A5E for ; Sun, 15 Nov 2009 19:09:30 -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 4wMkZ0xjT-NU for ; Sun, 15 Nov 2009 19:09:29 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 16DB33A6A61 for ; Sun, 15 Nov 2009 19:09:28 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1832049eyd.51 for ; Sun, 15 Nov 2009 19:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=JHVqph9R8TdW7xT0zBjwHJNMKeckSPFjY2EltN2MW18=; b=TjHfjgFMtY5TOZyaXhp1lteIzgkHFx009km1ugvH6jfO0J9x0QKnwiM7vEt3+oj+Ki /G3gGlli4u/NA7oV7twWTjEk2N7iJGT9Ba4IH4AoeNKdQFdyBa8kqZY2N4tPP2GkbCHS l5wbv6wMjUUZC7RwiRFRsh6SV5Maj5i6wNQCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=fi5KE3fCG0XU0Q8G41iFXkajTBAZkKZ/iUGuMno/6kkqZnU7j2mnCaw9zqcj1hII1J WkNln4YQcevKpDbiGR7B8/IJ62JNAKnkva+d2NUlL/Xd1FYK59K+URBdk3BUIgS0MiCl O860HoRd2ikYFuEBt5W9OUlkyq6E5Pt+MIfLE= Received: by 10.213.24.15 with SMTP id t15mr1511081ebb.89.1258340963559; Sun, 15 Nov 2009 19:09:23 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 28sm3706029eye.7.2009.11.15.19.09.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Nov 2009 19:09:23 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B00C259.5070103@jacaranda.org> Date: Mon, 16 Nov 2009 03:09:13 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AFF79A4.6020706@extendedsubset.com> <4B00662E.1020506@bolyard.me> <4B006AE1.30206@extendedsubset.com> <20091115233324.88BC069F83E@kilo.networkresonance.com> <4B00933D.7080601@extendedsubset.com> In-Reply-To: <4B00933D.7080601@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBB7DB311A6C8EF4981F66FE9" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 03:09:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBB7DB311A6C8EF4981F66FE9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > Eric Rescorla wrote: >> The only breakage I can see is that some >> clients will be unable to operate with old servers. This doesn't >> seem to have the effect you suggest at all. >=20 > Any proposed fix in which "some clients will be unable to operate with > old servers" is DOA at most sites because there is a painless > alternative which does not (disabling all renegotiation). Huh? Any server that upgrades is not one of the "old servers" that will break. That is necessarily the case because the upgrade (at least for Eric's draft) requires the server to be extension-tolerant. So the fact that there are other broken servers, does not influence any particular server operator's decision to upgrade. On the client side, disabling renegotiation is unnecessary, because it's possible (in the case where you still want the client to connect to unpatched servers) to only send the extension when renegotiating. And if you don't want the client to connect to unpatched servers, then there's no interoperability problem because all patched servers will be extension-tolerant. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigBB7DB311A6C8EF4981F66FE9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksAwmEACgkQWUc8YzyzqAfSEwEAh5IHAMbEjQ6ESikozTNzULhl KYqSqHRv2MtWCoFSPCABAIXXwh6kREBk3kKmpV+irsJxrkjqbMne/We3f9Rldv6B =UOY4 -----END PGP SIGNATURE----- --------------enigBB7DB311A6C8EF4981F66FE9-- From djhopwood@googlemail.com Sun Nov 15 19:16:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDAF63A6A63 for ; Sun, 15 Nov 2009 19:16:11 -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 1HUuVDWZhbFV for ; Sun, 15 Nov 2009 19:16:11 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id B87923A6A6A for ; Sun, 15 Nov 2009 19:16:10 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so946206eyd.5 for ; Sun, 15 Nov 2009 19:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=3rs1rginL79JMYJw+QMZ9TtPwCdOFn2YSGt2G/mpYgw=; b=YWqy6DofDFdZV5DHxUpUuiYr2YaYg5/goqYuvk8QIs5yxTq8zJMtLVsISOWtXB3QLv 9gcnSD5lviXAq89Nya+TGn1CHUm5rEnnM+94vGeJKIlJkwXpN93M8kJVfLrCydafJoGI LGnnCbu9IFeniPy7EKIJrcPY3z/k5K1I6KGRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=O+HZ7CVEyckB8wGBgj4oOrPyzO4+b8/qD/8KW6sIytT/n3WhHlbJnjYZ26y9PdbPkg U+wVf2NpajWYQj822l1+wH+Qql+xEq9gH1vBNUs3yFDuiJ2YtZ/vpUo/zR9SUseEiqed wfjGVyVb37+d2lSHtraFcDwVSnn9bD3sRgZ74= Received: by 10.213.24.22 with SMTP id t22mr1541579ebb.59.1258341365904; Sun, 15 Nov 2009 19:16:05 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 5sm3763219eyf.10.2009.11.15.19.16.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Nov 2009 19:16:05 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B00C3F2.5050309@jacaranda.org> Date: Mon, 16 Nov 2009 03:16:02 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AFF79A4.6020706@extendedsubset.com> <4B00ACBB.6060805@pobox.com> In-Reply-To: <4B00ACBB.6060805@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig74D9CC01E98BCA0CF80D74BA" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 03:16:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74D9CC01E98BCA0CF80D74BA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > With the RI extension, a client that wants to protect itself from an > unpatched server needs to abort the handshake before sending its > Finished message. This is the key -- neither side will know for > certain that an attack took place since Finished messages are not > exchanged, and can't be if you want to remove the possibility of an > attack. I don't see why that is a problem. Being able to prove that an attack took place (or to distinguish an attack from, say, line noise or any of many possible implementation errors) was not a design goal of TLS, and the protocol doesn't achieve that for numerous reasons. It is hard to see how a secure channel protocol could possibly achieve this goal, for active attacks. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig74D9CC01E98BCA0CF80D74BA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksAw/MACgkQWUc8YzyzqAdwfgD/QSZRBKxjzgCmGfM/Uan4cLYW /ZhJ9FCj8++y4lEik3IA/1rA8jqh4zOe1OSLizNZqIhrnUNK8gZ+A46KGE9HCuH0 =hmyg -----END PGP SIGNATURE----- --------------enig74D9CC01E98BCA0CF80D74BA-- From bmoeller@acm.org Sun Nov 15 19:29:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28563A6A5A for ; Sun, 15 Nov 2009 19:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.961 X-Spam-Level: X-Spam-Status: No, score=-101.961 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zgwCslJdAlRX for ; Sun, 15 Nov 2009 19:29:40 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by core3.amsl.com (Postfix) with ESMTP id BE0FC3A68EA for ; Sun, 15 Nov 2009 19:29:39 -0800 (PST) Received: from [10.1.65.88] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LhAEV-1Ny6TS3dDD-00oAgD; Mon, 16 Nov 2009 04:29:36 +0100 From: Bodo Moeller To: mrex@sap.com In-Reply-To: <200911160010.nAG0AP0f001956@fs4113.wdf.sap.corp> References: <200911160010.nAG0AP0f001956@fs4113.wdf.sap.corp> Message-Id: <64B5DE9F-10F4-4D7E-9762-6E16E130D43B@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 19:29:31 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX18REPn8Z5jaJkWWNL6Le13c6GRzMaVwwCnyojZ QeeIhvOC2weQTm0lWbh4YxFQAkwGR37UK5+JZzLX2W66yqGw0t uv3cnDYcG3i3+duDPLgNQ== Cc: tls@ietf.org Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 03:29:40 -0000 On Nov 15, 2009, at 4:10 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> Bodo Moeller wrote: >>> Why make a client send it on the initial handshake if that client >>> wouldn't have plans to abort the connection if the server doesn't >>> acknowledge it? Interoperability seems easier if you don't send it. >> Agreed. I've rethought this point since I wrote it. > I see value in extension-less signaling on initial handshake, > because it will immediately provide protection to updated clients > when the server is updated even when both, client and server still > support the insecure renegotiation (i.e. very early in the > transition period) or the client still allowys a reconnect > fallback with an extension-less ClientHello. Thanks, I can see your point. My assumption was that we wouldn't mind breaking legacy renegotiation handshakes (we'd expect all servers that allow renegotiation to be updated such that they *never* allow legacy renegotiation), and that we'd just want *initial* handshakes to continue to work between updated clients and current servers. That's just enough backwards compatibility such that client-side users can actually update their software without having to wait for all servers to get updated first. I'm not convinced that we'd want updated servers to offer legacy renegotiation, but if we do, then using a pseudo ciphersuite seems fine to let the client indicate that it doesn't want legacy renegotiation (i.e., the present handshake is not a renegotiation handshake, and if the servers sees it as one, it should abort the connection immediately because it's with a MitM). Bodo From mike-list@pobox.com Sun Nov 15 20:34:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D553A68B8 for ; Sun, 15 Nov 2009 20:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 Sp8ouXJQdWNY for ; Sun, 15 Nov 2009 20:34:41 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id C623F3A68AB for ; Sun, 15 Nov 2009 20:34:40 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1890980330 for ; Sun, 15 Nov 2009 23:34:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=8lkNDMIiVxCJ XhJYK2Ir48adSdU=; b=t3IUiXjpQjdLxI/iKmYgByxFisGwZR0u5kk2Rw/nIaRW nT44Y6VP2LSuLiSSQSWqinaahe/zCNcVfA1E86tzOWv4Qx/Go4OZBatXZktVcQK3 CJKcIR3SGYZnx7cwJ33O2PmcRGuxCjihk/U0xZrnpxgUBuU1/t68ot4UEEX3zt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=erw/tt UOywtpSrmqjhlrH8JyDND3AQGZDi8aW/vyVenVfavXA2n6YCXafZwX5HV5J6SUqn AxF61imYyO4Ex5ldHuQE2exDGZIdidDVo5o0kC0fCN/r9oRLPfePsJlI98+bcaH2 CiF6/KMhIlLkP9S81l5G2dqGYXsvBB8GpS50I= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 14FAC8032F for ; Sun, 15 Nov 2009 23:34:38 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 6E4A080326 for ; Sun, 15 Nov 2009 23:34:37 -0500 (EST) Message-ID: <4B00D699.7030902@pobox.com> Date: Sun, 15 Nov 2009 20:35:37 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> In-Reply-To: <4B00AE09.8050906@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 595FB49E-D269-11DE-9FAB-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 04:34:43 -0000 >> RI with patched client / unpatched server: >> >> People continue to suggest that with the RI extension, a client doesn't >> need to send it on its initial handshake. This is completely wrong. > > It is not "completely wrong". For a patched client, not sending a signal > on the initial handshake (regardless of the form of that signal) matters > if-and-only-if the client is going to refuse to interoperate with > unpatched servers. "Interoperating with unpatched servers" means exposing yourself to an attack. We can't protect against that behavior. It may initially be necessary to do this until widespread adoption of the fix happens, but it is certainly not safe long term. Any fix that we come up with, if it is not used it will not protect you. That is obvious. > If a client would continue with an initial connection to a server that it > knows is unpatched, then the attack is unavoidable in that case. That is > true for *any* possible solution, not just RI. Agreed. The difference is that if you *DO* want to avoid handshaking with unpatched servers then with RI it requires you to a) use TLS, not SSL, because you need to b) send and receive an extension; you also c) base your decisions on in- the-clear hello messages that are subject to tampering, and d) don't send a Finished message if the server *appears* not to support RI, thus you can't prove or disprove an attack was underway. With my proposal, you simply switch to a new Finished message calculation; no changes to the bits on the wire, thus perfectly interoperable up until the Finished message fails because the server is not upgraded. And that is what you want to happen if you are not being "lenient." Further, if an attack is happening and the server *is* upgraded, it can prove it since neither of the two Finished calculations will match. A MITM can not do anything to cause one of them to match since it doesn't know the master secret. >> A MITM attack will absolutely succeed if the server is not patched and >> the client does nothing different than it always has in the past. Thus >> if RI is not used by the client in its first handshake, it gets zero >> protection even though it is aware of the MITM attack. And even if the >> client does use the extension, it must rely on a possibly forged Server >> Hello to decide whether to continue with the handshake. >> >> So the client has to send the extension on every handshake including >> the initial handshake. This brings up all of the interoperability >> problems: lack of support for extensions even in TLS, no possible way >> to use extensions with SSLv3, mischief by a MITM (removing the >> extension from the hello messages, simulating a server "crash" when >> the extension is sent, etc.) > > These kinds of "mischief by a MITM" won't work. The Finished hashes will > fail to verify, and the attacker gains no advantage: In most cases I think you are right, but imagine there is a server out there that requires renegotiation to obtain client credentials. In order to continue providing service to clients, it may be configured to still perform insecure renegotiations during a transition period. A MITM can easily make this server appear to break upon receiving the RI extension. If the client has a fallback to not use the RI extension, then the MITM is able to cause the client and server, both of which are patched, to revert back to insecure behavior. With my proposal, it is also possible for a MITM to alter the handshake, but the difference is that the server can prove it happened since neither Finished computation will match. Because it notices an active attack, it can mount a more effective defense, such as locking out that client's IP address (range) from renegotiating and instead ask for client auth in the initial handshake. >> This solution is to make available a modified Finished calculation that a >> patched client can use for all handshakes including the initial one. This >> solution does not even break compatibility with old clients -- a server >> would support BOTH the old and the new Finished message computation and do >> the right thing based on which one was used by the client. > > This has a significant disadvantage relative to the RI proposal: > Consider a patched client that wants to connect to unpatched servers. > With your suggested approach, such a client must use the old Finished > message computation on an initial handshake (or else it must add a fallback > in order to connect to those servers, which is undesirable). Therefore, it > isn't distinguishable from an unpatched client by looking at cleartext > handshake messages. I'm suggesting to give up cleartext patch status for better attack detection and better interoperability since there is NO change to bits on the wire, no need for extensions or even TLS (SSLv3 can be fixed in exactly the same way). A server can actually log when neither Finished message calculation matches and alert the proper people to investigate the attack. With RI this is not possible since the client can't send its Finished message without risking an attack. > My proposal of changing the Finished hash computation for renegotiations > only, plus sending an empty extension to signal patched status, does not > have this disadvantage. It also does not rely on the extension for > anything other than detection of patched/unpatched status. This has the same problems as RI w.r.t. not being compatible with SSLv3 and requiring extensions. But it would work for peers that both support TLS with extensions. >> The only interoperability "problem" is when a patched client uses the new >> Finished calculation when talking to an unpatched server[*] -- the >> handshake will fail. This is precisely what SHOULD happen -- the client >> is protected from a potential MITM attack! > > It is quite unrealistic to suppose that *all* client implementors will > want to refuse to interoperate with unpatched servers. That has to be > an option, not a requirement or assumption. The whole premise of my message was based on providing a solution for a patched client trying to protect against an unpatched server. Any solution we come up with MUST protect a patched client talking to a patched server, so the only issue worth discussing is how to protect patched clients from an unpatched server. Or if a proposed solution fails the MUST, such as with the fallback possibility when an RI client can be tricked into reconnecting insecurely and a server accepting it. If a client wants to throw caution to the wind and connect using the old Finished message, that is its choice. Nobody can force a client to be secure if it doesn't want to be. That does not mean that we shouldn't provide a completely secure method to avoid and detect these attacks. Mike From peter.robinson@rsa.com Sun Nov 15 20:50:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A4E3A6A6D for ; Sun, 15 Nov 2009 20:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NORMAL_HTTP_TO_IP=0.001, 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 YwqBPv0DChtS for ; Sun, 15 Nov 2009 20:50:15 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 704083A6782 for ; Sun, 15 Nov 2009 20:50:15 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nAG4oDun012912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 Nov 2009 23:50:13 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Sun, 15 Nov 2009 23:50:12 -0500 Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2mp) with ESMTP id nAG4oCSC027318 for ; Sun, 15 Nov 2009 23:50:12 -0500 Received: from CORPUSMX100B.corp.emc.com ([128.222.76.52]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Nov 2009 23:50:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 15 Nov 2009 23:50:06 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0814_01CA66CC.164395D0" Message-ID: In-Reply-To: <4B00D699.7030902@pobox.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: RSA BSAFE TLS Interoperability Server Thread-Index: AcpmdiKjcFBxHoWKSiSqfxwnm4j1vgAAVbTQ References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> <4B00D699.7030902@pobox.com> From: To: X-OriginalArrivalTime: 16 Nov 2009 04:50:12.0199 (UTC) FILETIME=[47E83770:01CA6678] X-EMM-EM: Active Cc: kathy.kriese@rsa.com Subject: [TLS] RSA BSAFE TLS Interoperability Server X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 04:50:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0814_01CA66CC.164395D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RSA, The Security Division of EMC, has created a TLS Interoperability Server to allow inter-op testing of TLS. The static content of the server is here http://203.166.62.199/ Please email me the following information so I can have your IP address added to a white list so you can access the inter-op servers themselves. * Contact Information Name Organization or Company name and Business Unit Address Phone Number Email address * IP Address(es) which you will be connecting from. * Product(s) and version(s) you will be testing. * TLS protocol versions, cipher suites and curves you wish to test. Peter ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. ------=_NextPart_000_0814_01CA66CC.164395D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWmzCCAucw ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1 s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5 IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3 Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/ eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5 /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1 cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13 qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggR+MIID56ADAgECAhEAsSe9 yNTH2rYKRiN7F8KhkTANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT MB4XDTA5MDcyMTA1MTYxM1oXDTExMDcyMjA1MTYxM1owgekxEzARBgoJkiaJk/IsZAEZFgNjb20x EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjEMMAoGA1UECxMD UlNBMRUwEwYDVQQLEwxBc2lhL1BhY2lmaWMxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQF EwYwNjQ4MTQxFzAVBgoJkiaJk/IsZAEBEwdyb2JpbnAyMRcwFQYDVQQDEw5QZXRlciBSb2JpbnNv bjElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA2CcjIV2QNoJP4YbPejhZX2MSu53/EooTnrkf7M4gsl1DobXkk3CO6kU9bN6O wwL/o87dQ4y2FHjwkV4WeoodhvZa08q5uX4vZCtB2Hn0OUrbPzyKl7wXSq+yezKCQJBrVCTwWjKK A6Gqc1VhkqWSBCpUaQ39TsVDxNYCGIn433cCAwEAAaOCAX8wggF7MIGSBgNVHSAEgYowgYcwgYQG CSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5o dG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9y YXRlZCBieSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnBldGVyLnJvYmluc29uQHJzYS5jb20wDgYDVR0PAQH/BAQDAgeAMEYG A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQm 7p962rS9dUpGeQZt+Vi1su6tQTANBgkqhkiG9w0BAQUFAAOBgQCghPP5wxcDJuACPYJ/U1sjhyE4 gxpGKZNPnnDcjfHo+Cq87cWawpV5Rzpg8KVZc0EoG6BabGNyk+WgZMjCzADpg+appN4cX+DML0ir 3cBcX8pQTuKw1VRlUjidjkTIl/Z2hrcvgh2lJG+PFV2ogWICzwOj4/zKG4khs9VO5NNPezCCBI4w ggP3oAMCAQICEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFS U0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xh c3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czELMAkGA1UEBhMCVVMwHhcNMDkwNzIxMDUxNjE4WhcNMTEwNzIyMDUxMzM2WjCB7TETMBEGCgmS JomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0 aW9uMQwwCgYDVQQLEwNSU0ExFTATBgNVBAsTDEFzaWEvUGFjaWZpYzEUMBIGA1UECxMLRW5naW5l ZXJpbmcxDzANBgNVBAUTBjA2NDgxNDEXMBUGCgmSJomT8ixkAQETB3JvYmlucDIxGzAZBgNVBAMT ElBldGVyIFJvYmluc29uLUVuYzElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqeM4888BmvaveugOJqTYWGNm3cTP6qJe444S 7AJaXDnKZlt1cJByB+B83hdGGe2FyRQGGef0DNZhQIfaa41dzZbDWuogZ3mKxyuOhciZSoRoCIM0 jlPh5vqhDmXBPFQ/EedNPRk+tl+mKVz2fHbsI01bWtueV05BvJu330cj0WUCAwEAAaOCAYswggGH MDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDCB kgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwUwdzAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNl Y3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMC AQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCEGA1UdEQQaMBiBFnBldGVyLnJvYmlu c29uQHJzYS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206 ODAvUlNBQ2xhc3MyUGVyc29uYWxDQS5jcmwwHwYDVR0jBBgwFoAUxpPuxqX+41WOz4ojH+6Y3iHy n6cwHQYDVR0OBBYEFGg/pAQlQSo2dvZeyryhS2toL395MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG 9w0BAQUFAAOBgQCY/nGMkd29x8wULeVsTP+emR/XVn+LqcfwzgwpUSKP1FX1WedrHwlNKFaVDjQX FaNETkV4XzMugf4iafsgZUp5DmzIOBB5H5MI1k+CprZ0tjet7gcN0sdCt0fggfw44GZ37rwxzwyt XZrbEePtb8wFYVEobKBD/ZqvghavL93K3DGCA4EwggN9AgEBMIGiMIGMMRowGAYDVQQKExFSU0Eg U2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3Mg MiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEL MAkGA1UEBhMCVVMCEQCxJ73I1MfatgpGI3sXwqGRMAkGBSsOAwIaBQCgggI0MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExNjA0NTAwNlowIwYJKoZIhvcNAQkE MRYEFGjfrY8z/3f8roPETDJQnul+iN4eMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA nRPzfc178B+eDmgcvMWAJJcUO+eRSUFm+e1iK0KExymn1RENJjd287DD62tBzovhKMxWNEuVXEKS fRHCT0VF3Krl5voZPGnKlMM3F3KyS5OY+vkScuCY3AC3IYW2oZwWisEyKphbbzg6tL88SK+apx/e i7frhBdPEjczqAHq3e4AAAAAAAA= ------=_NextPart_000_0814_01CA66CC.164395D0-- From bmoeller@acm.org Sun Nov 15 21:18:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA1F3A6A7A for ; Sun, 15 Nov 2009 21:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Sdr6JfzxvpVL for ; Sun, 15 Nov 2009 21:18:30 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id B1C293A67E4 for ; Sun, 15 Nov 2009 21:18:29 -0800 (PST) Received: from [10.1.65.88] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MfBqk-1NYbrR2Jju-00OCSo; Mon, 16 Nov 2009 06:18:25 +0100 From: Bodo Moeller To: Michael D'Errico In-Reply-To: <4B00D699.7030902@pobox.com> References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> <4B00D699.7030902@pobox.com> Message-Id: <9EBF6B9D-71E0-4607-A5DC-9B219C5E6F73@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Nov 2009 21:18:20 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+SS61JllLL7N3TID0gNmiBRRBpKVuLQ5Ux0U0 T/xuS9rTAoE7abdMWa/XwEk/vKeKTfQKoP6Nzk0hATs15MnrxC MwY8gsYi1xFERuxezzBtQ== Cc: tls@ietf.org Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 05:18:30 -0000 On Nov 15, 2009, at 8:35 PM, Michael D'Errico wrote: > The difference is that if you *DO* want to avoid handshaking with > unpatched > servers then with RI it requires you to a) use TLS, not SSL, because > you need > to b) send and receive an extension; you also c) base your decisions > on in- > the-clear hello messages that are subject to tampering, and d) don't > send a > Finished message if the server *appears* not to support RI, thus you > can't > prove or disprove an attack was underway. > > With my proposal, you simply switch to a new Finished message > calculation; > no changes to the bits on the wire, thus perfectly interoperable up > until > the Finished message fails because the server is not upgraded. And > that is > what you want to happen if you are not being "lenient." Further, if > an > attack is happening and the server *is* upgraded, it can prove it > since > neither of the two Finished calculations will match. A MITM can not > do > anything to cause one of them to match since it doesn't know the > master > secret. Where we are requiring changes in both clients and servers anyway, I don't see a problem about using an extension in a SSL 3.0 handshake. We can just assume that the updated software will support this one extension (while maybe ignoring any other extension). >>> So the client has to send the extension on every handshake >>> including >>> the initial handshake. This brings up all of the interoperability >>> problems: lack of support for extensions even in TLS, no >>> possible way >>> to use extensions with SSLv3, mischief by a MITM (removing the >>> extension from the hello messages, simulating a server "crash" >>> when >>> the extension is sent, etc.) >> These kinds of "mischief by a MITM" won't work. The Finished hashes >> will >> fail to verify, and the attacker gains no advantage: > > In most cases I think you are right, but imagine there is a server > out there > that requires renegotiation to obtain client credentials. In order to > continue providing service to clients, it may be configured to still > perform > insecure renegotiations during a transition period. A MITM can > easily make > this server appear to break upon receiving the RI extension. > > If the client has a fallback to not use the RI extension, then the > MITM is > able to cause the client and server, both of which are patched, to > revert > back to insecure behavior. If both the client and the server allow this fallback to legacy renegotiation, they might be downgraded to insecure behavior. We have a proposal that could be used to avoid this without extensions, though: have the client list use a magic ciphersuite to indicate support for the new handshake scheme. If the server sees this listed by the client, it would refuse this Client Hello in a renegotiation handshake. I don't see how your proposal would avoid the problem: A client that wants to support legacy servers couldn't use the modified Finished computation in the first place. But if it doesn't, it wouldn't be secure, would it? Bodo From benl@google.com Sun Nov 15 21:38:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854923A6358 for ; Sun, 15 Nov 2009 21:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 9h1fE5zBfCSW for ; Sun, 15 Nov 2009 21:38:08 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 4B0183A67EF for ; Sun, 15 Nov 2009 21:38:08 -0800 (PST) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id nAG5c5If006334 for ; Mon, 16 Nov 2009 05:38:05 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258349886; bh=8d6/c0CN29jATxaU4uKi2d9CQuE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=eWhPRqwKfvM+hBzggu/WlYQNOuQJHWHPCCkxpu9dohgWOSXTwbH5CAPM2ihG+ovmH 9x4tfaDvWEGL0WirnddgA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=v8ffqn5TJhLbnkKfYxrxy+R296aaarxEyAVLh2aiM2+l8o5omb3vCZNbX7xuch1yv DYeHGabP8IEBMu8hshYtA== Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by zps38.corp.google.com with ESMTP id nAG5c2Y3007022 for ; Sun, 15 Nov 2009 21:38:02 -0800 Received: by qyk29 with SMTP id 29so2365851qyk.32 for ; Sun, 15 Nov 2009 21:38:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.23.74 with SMTP id q10mr1009483qcb.63.1258349882150; Sun, 15 Nov 2009 21:38:02 -0800 (PST) In-Reply-To: References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> <4B00D699.7030902@pobox.com> Date: Sun, 15 Nov 2009 21:38:02 -0800 Message-ID: <1b587cab0911152138q613aa1f5o492f856f2486a185@mail.gmail.com> From: Ben Laurie To: peter.robinson@rsa.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: kathy.kriese@rsa.com, tls@ietf.org Subject: Re: [TLS] RSA BSAFE TLS Interoperability Server X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 05:38:09 -0000 On Sun, Nov 15, 2009 at 8:50 PM, wrote: > RSA, The Security Division of EMC, has created a TLS Interoperability Server > to allow inter-op testing of TLS. Does it support the renegotiation extension? From ekr@networkresonance.com Sun Nov 15 21:43:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5383A68AB for ; Sun, 15 Nov 2009 21:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvErxsCW00ul for ; Sun, 15 Nov 2009 21:43:50 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 789BA3A67AD for ; Sun, 15 Nov 2009 21:43:50 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9uNR-0003w7-00 for tls@ietf.org; Mon, 16 Nov 2009 07:43:49 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id BB00D69F87D; Mon, 16 Nov 2009 07:45:06 +0200 (EET) Date: Mon, 16 Nov 2009 07:45:05 +0200 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B009CF8.800@extendedsubset.com> References: <4B008F6D.7070303@pobox.com> <4B009CF8.800@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116054506.BB00D69F87D@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 05:43:51 -0000 At Sun, 15 Nov 2009 18:29:44 -0600, Marsh Ray wrote: > > Joseph Salowey (jsalowey) wrote: > > [Joe] I disagree. If the client has a lenient policy, meaning it will > > connect with unpatched servers, then it doesn't need to send the > > extension. If the client has a strict policy then it needs to send the > > extension, in this case it only needs to interoperate with servers that > > support the extension. I'm not sure what scenario you are trying to > > address. > > Well, for example, the server doesn't want to accept vulnerable > connections from unpatched clients. Some attacks are possible even if > the server does not renegotiate. What attacks are those? > How often do SSL/TLS clients actually refuse renegotiation at the > request of a patched server? I don't understand the relevance of this question. > Do we really want a situation where a patched client is talking to a > patched server, yet neither of them know it? I don't see the problem ehre. > If an extension is really the solution, why wouldn't the client send one > every time? How does it help to make it conditional? It avoids the claimed backward compatibility problem with > Does thus segment the protocol into "client will renegotiate" and > "client won't renegotiate" versions? Does the client have to decide that > in advance? No, it doesn't segment the population. You can still renegotiate even if you didn't send the extension on initial handshake. > If the client does send the extension does that imply he will in fact be > willing to renegotiate later? If not, how will developers test that odd > case? As I said before, not sending the extension does not mean you wouldn't renegotiate. -Ekr From mike-list@pobox.com Sun Nov 15 21:46:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF283A6A83 for ; Sun, 15 Nov 2009 21:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 g8EYNPjP25ZS for ; Sun, 15 Nov 2009 21:46:10 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 2F7713A6A82 for ; Sun, 15 Nov 2009 21:46:10 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EA77F80793 for ; Mon, 16 Nov 2009 00:46:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=pe4V4KlC5BcN OlK8bvIMV1FYyWc=; b=kF1sU/RcsHOD2XaCb11wAaOb2u4/eKzKokqk1mIpQOuG qZIW9kl8x1I44b2gYNsCMZxpCUCtmUxmh1gyMXxHNJc/vj5zdUs5OIOvoCQFIYec 3CaDVcDMHcAg6+SrC5NhI1aM7w9Db+thbk21W3V8CI6DhC+L+lR/+LZTpD+v1Lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=tyfFT2 ghk3s/VxYUSrds2eUdbEV0m7q0UJfBWHJ9UXGUBMNGCbn7HsVOb/tuBytTcIMV18 J3GQimBqHeLXhtfb82CMywq8gO04RAzMW+/W6yXb9iD0byLVnl8O+C/jzMJA7xGz yXfPYXArJ8KyeEpD/93FJxkkC4G+6WYpAsOnU= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DEAEF80792 for ; Mon, 16 Nov 2009 00:46:07 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 50B4F80791 for ; Mon, 16 Nov 2009 00:46:07 -0500 (EST) Message-ID: <4B00E75B.3020202@pobox.com> Date: Sun, 15 Nov 2009 21:47:07 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> <4B00D699.7030902@pobox.com> <9EBF6B9D-71E0-4607-A5DC-9B219C5E6F73@acm.org> In-Reply-To: <9EBF6B9D-71E0-4607-A5DC-9B219C5E6F73@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 564A3A90-D273-11DE-83B2-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 05:46:11 -0000 > Where we are requiring changes in both clients and servers anyway, I > don't see a problem about using an extension in a SSL 3.0 handshake. We > can just assume that the updated software will support this one > extension (while maybe ignoring any other extension). Patched clients talking to patched servers is not the issue since they won't be vulnerable anyway. We need to focus on interoperability between peers where only one of them is patched. There are likely going to be lots of interoperability problems caused by RI with SSLv3 servers since they don't currently expect any extensions. >> If the client has a fallback to not use the RI extension, then the >> MITM is >> able to cause the client and server, both of which are patched, to revert >> back to insecure behavior. > > If both the client and the server allow this fallback to legacy > renegotiation, they might be downgraded to insecure behavior. We have a > proposal that could be used to avoid this without extensions, though: > have the client list use a magic ciphersuite to indicate support for the > new handshake scheme. If the server sees this listed by the client, it > would refuse this Client Hello in a renegotiation handshake. It's good that an extension is not needed, but how does the client find out that the server recognized it? It can't send its Finished message safely unless it knows for sure the server is patched. > I don't see how your proposal would avoid the problem: A client that > wants to support legacy servers couldn't use the modified Finished > computation in the first place. But if it doesn't, it wouldn't be > secure, would it? A so-called "lenient" client might as well just continue using the old (current) handshake and hope that all the servers it talks to are patched. This is true for both RI and my proposal. Mike From ekr@networkresonance.com Sun Nov 15 21:48:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6C13A6A82 for ; Sun, 15 Nov 2009 21:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5YEn0cJ01B3 for ; Sun, 15 Nov 2009 21:48:36 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 03CA13A68F2 for ; Sun, 15 Nov 2009 21:48:36 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9uS3-0005Jr-00 for tls@ietf.org; Mon, 16 Nov 2009 07:48:35 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id A520469F87E; Mon, 16 Nov 2009 07:49:52 +0200 (EET) Date: Mon, 16 Nov 2009 07:49:51 +0200 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911160048.nAG0mPEP015280@fs4113.wdf.sap.corp> References: <20091116002354.6EEC269F857@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116054952.A520469F87E@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 05:48:36 -0000 At Mon, 16 Nov 2009 01:48:25 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > I know there has been a bunch of discussion about the prevalance of > > SSLv3-only stacks. As one data point, Lee, Malkin, and Nahum's 2007 > > IMC paper (http://www.imconf.net/imc-2007/papers/imc130.pdf) indicates > > 98+% deployment of TLS on Web servers. > > So? Servers are in much safer position to support newer > TLS protocol versions, because they get to choose. I don't know what "So" means. The question of what is safe for clients to do depends on what servers support. I'm offering data towards that question. > Clients bear the burden to make safe assumptions about what is going > to be interoperable with the server, and safe protocol features > are the reason why the amount of traffic on the internet that is > still using prtocol version 0x03,0x00 (aka SSLv3) is _MUCH_ larger > as the amount of public Web Servers that supports TLS. I'd be interested in seeing the data that supports the claim that it is much larger. Can you provide references please? -Ekr From ekr@networkresonance.com Sun Nov 15 21:49:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8635A3A6A87 for ; Sun, 15 Nov 2009 21:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4vsIPb6PBdM for ; Sun, 15 Nov 2009 21:49:44 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id BB7F43A6A86 for ; Sun, 15 Nov 2009 21:49:44 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9uT9-0005a8-00 for tls@ietf.org; Mon, 16 Nov 2009 07:49:43 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9D38969F87F; Mon, 16 Nov 2009 07:51:01 +0200 (EET) Date: Mon, 16 Nov 2009 07:51:01 +0200 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B00A2B0.70804@extendedsubset.com> References: <200911160048.nAG0mPEP015280@fs4113.wdf.sap.corp> <4B00A2B0.70804@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116055101.9D38969F87F@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 05:49:45 -0000 At Sun, 15 Nov 2009 18:54:08 -0600, Marsh Ray wrote: > > Martin Rex wrote: > > > > What this statistics likely does not cover is Intranet Servers > > that offer TLS. Some of these run vital applications for companies. > > It bears repeating that SSL/TLS is much much more than https. Of course it is. I'd certainly be interested in seeing whatever data you can provide. > What worries me are deployments like [all the parking meters and traffic > lights in ]. > > Or look at all the little plastic boxes returned from searches like this: > http://search.hp.com/query.html?qt=ssl/tls And what fraction of those devices will patch at all? -Ekr From ekr@networkresonance.com Sun Nov 15 21:55:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B4F3A687A for ; Sun, 15 Nov 2009 21:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.06 X-Spam-Level: X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU6g5KzrMSw4 for ; Sun, 15 Nov 2009 21:55:50 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 3975A3A6A6F for ; Sun, 15 Nov 2009 21:55:49 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9uZ2-0007GL-00 for tls@ietf.org; Mon, 16 Nov 2009 07:55:48 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 031E269F880; Mon, 16 Nov 2009 07:57:05 +0200 (EET) Date: Mon, 16 Nov 2009 07:57:05 +0200 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B00E75B.3020202@pobox.com> References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> <4B00D699.7030902@pobox.com> <9EBF6B9D-71E0-4607-A5DC-9B219C5E6F73@acm.org> <4B00E75B.3020202@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116055706.031E269F880@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 05:55:50 -0000 At Sun, 15 Nov 2009 21:47:07 -0800, Michael D'Errico wrote: > > > Where we are requiring changes in both clients and servers anyway, I > > don't see a problem about using an extension in a SSL 3.0 handshake. We > > can just assume that the updated software will support this one > > extension (while maybe ignoring any other extension). > > Patched clients talking to patched servers is not the issue since they > won't be vulnerable anyway. We need to focus on interoperability between > peers where only one of them is patched. > > There are likely going to be lots of interoperability problems caused by > RI with SSLv3 servers since they don't currently expect any extensions. Again, this only obtains if the client sends RI on the initial handshake which it only does if it is strict and would refuse to handshake with an insecure server. > >> If the client has a fallback to not use the RI extension, then the > >> MITM is > >> able to cause the client and server, both of which are patched, to revert > >> back to insecure behavior. > > > > If both the client and the server allow this fallback to legacy > > renegotiation, they might be downgraded to insecure behavior. We have a > > proposal that could be used to avoid this without extensions, though: > > have the client list use a magic ciphersuite to indicate support for the > > new handshake scheme. If the server sees this listed by the client, it > > would refuse this Client Hello in a renegotiation handshake. > > It's good that an extension is not needed, but how does the client find > out that the server recognized it? It can't send its Finished message > safely unless it knows for sure the server is patched. Again, it can if it's willing to negotiate with unpatched servers, which many clients will be for the foreseeabe future. > > I don't see how your proposal would avoid the problem: A client that > > wants to support legacy servers couldn't use the modified Finished > > computation in the first place. But if it doesn't, it wouldn't be > > secure, would it? > > A so-called "lenient" client might as well just continue using the old > (current) handshake and hope that all the servers it talks to are > patched. This is true for both RI and my proposal. No, that's not correct. The purpose of RI is twofold: 1. To allow a lenient client to RENEGOTIATE with a patched server, which would otherwise refuse to renegotiate. 2. To allow a strict client to detect whether a server is patched. The first benefit is what is relevant here. -Ekr From jsalowey@cisco.com Sun Nov 15 22:31:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D95B3A6870 for ; Sun, 15 Nov 2009 22:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 bzgVLhzcy7aV for ; Sun, 15 Nov 2009 22:31:12 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5E1C63A6808 for ; Sun, 15 Nov 2009 22:31:12 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPt/AEurR7H+/2dsb2JhbAC9P5YThDwE X-IronPort-AV: E=Sophos;i="4.44,749,1249257600"; d="scan'208";a="271443320" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2009 06:31:11 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAG6VBSC020973; Mon, 16 Nov 2009 06:31:11 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Nov 2009 22:31:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 22:31:10 -0800 Message-ID: In-Reply-To: <200911160036.nAG0atRS014903@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpmVP5f83tizcggRZ6cb6pKy386+wAL6Iew References: <200911160036.nAG0atRS014903@fs4113.wdf.sap.corp> From: "Joseph Salowey (jsalowey)" To: , X-OriginalArrivalTime: 16 Nov 2009 06:31:11.0757 (UTC) FILETIME=[63AF63D0:01CA6686] Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 06:31:13 -0000 =20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Martin Rex > Sent: Sunday, November 15, 2009 4:37 PM > To: tls@ietf.org > Subject: [TLS] simplistic renego protection >=20 > The most simplistic approch to renego protection is >=20 > 1. the client signals that it is patched through a fake > ciphersuite ID in each ClientHello >=20 > 2. the client only supports secure renegotiation and > secure renegotiation is specified to change the definition > of the handshake message hash for renegotiation handshakes > to include the verify_data of the client.finished and > server.finished after the ServerHello. >=20 > Everything else is options for vendors and users. >=20 > If we do not provide a standardized signaling Server->Client=20 > in the client hello, then it is not possible for the clients=20 > to offer the option for insecure renegotiation (I have no=20 > idea whether such a desire exists, but it might easily exist=20 > during transition). >=20 > With this simplistic approach, an MITM can not proxy a=20 > clients initial handshake into an updated servers=20 > renegotiation, even when the server still allows insecure=20 > renegotiation (e.g. during the transition period). =20 >=20 >=20 > I really like to hear convincing arguments why we need the=20 > TLS extension in the renegotiation handshake, and why=20 > changing the definition for the handshake message hash=20 > instead is not a superior alternative. In particular one=20 > that will grow naturally into future TLS revisions. >=20 [Joe] TLS Extensions is the standard way to extend the protocol. Using the ciphersuite field as a means to change the base protocol is a new extension mechanism. I don't think this is a particularly good thing for TLS to grow into. I don't see a reason to define a new extension mechanism when we can achieve what is necessary using the existing mechanism. When TLS 1.2+x is defined in the future then it can address the renegotiation problem as necessary and the version field will signal the underlying changes. =20 > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From djhopwood@googlemail.com Mon Nov 16 01:07:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7703D3A686C for ; Mon, 16 Nov 2009 01:07:18 -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 vjRvdXIMQHPB for ; Mon, 16 Nov 2009 01:07:17 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id C747B3A67A3 for ; Mon, 16 Nov 2009 01:07:16 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so938459fga.13 for ; Mon, 16 Nov 2009 01:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=is4k1Q5oEQhEHBe7LApg1VF+m+uunbKf5KJ1qKZbLSo=; b=s5D41oo0qjuTtNww1OJ/nlYYdpNzNL+ffixMAlq847mNBleKS9j63Y3MdjwmoyUj8x 4DQIcKmBHZz3lELP1LW88+uBGmP7dwUhMMzsapeYhOCOLfzONkjmOCkXcL531ycvfoPO okNqawOu9d6GvZzG6k6rocXShP79AIho9BbDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=QnZ1Y0+v/FJVuwAsJ2e7eNR8SyCQGZxNrJ3RUBAnKQuxoQepsMTNN2HF2Nud0F9M1r LU0hb/74+KBC5CcZGujn7J4OzCiVKhTCILK2paUyRWwvxAOU/aMdTux0jxUyFCREfZOT ZiAG0rCIg/9OYQDLioaIkTsUwy+ahb6DJ4iPI= Received: by 10.86.187.38 with SMTP id k38mr1161660fgf.5.1258362432675; Mon, 16 Nov 2009 01:07:12 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id l19sm4271937fgb.16.2009.11.16.01.07.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 01:07:11 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B01162F.9050708@jacaranda.org> Date: Mon, 16 Nov 2009 09:06:55 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> <4B00D699.7030902@pobox.com> In-Reply-To: <4B00D699.7030902@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig222E6FF343AE8818C2A48F8C" Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 09:07:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig222E6FF343AE8818C2A48F8C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: >>> RI with patched client / unpatched server: >>> >>> People continue to suggest that with the RI extension, a client >>> doesn't need to send it on its initial handshake. This is complet= ely wrong. >> >> It is not "completely wrong". For a patched client, not sending a sign= al >> on the initial handshake (regardless of the form of that signal) matte= rs >> if-and-only-if the client is going to refuse to interoperate with >> unpatched servers. >=20 > "Interoperating with unpatched servers" means exposing yourself to an > attack. > We can't protect against that behavior. It may initially be necessary = to > do this until widespread adoption of the fix happens, but it is certain= ly > not safe long term. I didn't say that it was. The solution must support at least both strict and lenient client policie= s, i.e. either refusing or allowing connections to unpatched servers. I don'= t think there is any dispute about that, is there? >> If a client would continue with an initial connection to a server that= it >> knows is unpatched, then the attack is unavoidable in that case. That = is >> true for *any* possible solution, not just RI. >=20 > Agreed. >=20 > The difference is that if you *DO* want to avoid handshaking with unpat= ched > servers then with RI it requires you to a) use TLS, not SSL, More precisely, it requires you to send a TLS ClientHello. It is possible= for an SSL-only server to recognize that ClientHello and negotiate SSLv3,= but still use the extension. That is, RI only requires servers to support extensions and be TLS-tolera= nt, not necessarily to be able to negotiate TLS. RI does require *clients* to= support TLS (since sending the ClientHello with a TLS client version promises that TLS is supported, and since the interoperability consequenc= es of sending an SSLv3 ClientHello with extensions are completely untested).= > because you need to b) send and receive an extension; you also c) base > your decisions on in-the-clear hello messages that are subject to tampe= ring, This is discussed below. > and d) don't send a Finished message if the server *appears* not to > support RI, thus you can't prove or disprove an attack was underway. I addressed this point before: # Being able to prove that an attack took place (or to distinguish an att= ack # from, say, line noise or any of many possible implementation errors) wa= s # not a design goal of TLS, and the protocol doesn't achieve that for # numerous reasons. > With my proposal, you simply switch to a new Finished message calculati= on; > no changes to the bits on the wire, thus perfectly interoperable up unt= il > the Finished message fails because the server is not upgraded. Yes, I wasn't arguing that your proposal had any interoperability problem= s. >> These kinds of "mischief by a MITM" won't work. [...] >=20 > In most cases I think you are right, but imagine there is a server out > there that requires renegotiation to obtain client credentials. OK... > In order to continue providing service to clients, it may be configured= > to still perform insecure renegotiations during a transition period. Then it is not fixed, and is nonconformant to the RI draft. > A MITM can easily make this server appear to break upon receiving the > RI extension. If the client has a fallback to not use the RI extension,= > then the MITM is able to cause the client and server, both of which are= > patched, to revert back to insecure behavior. That's not clear. I think it depends on precisely how the fallback mechanism is implemented. If the patched client refuses to renegotiate when it is in fallback mode, then I cannot immediately see any attack. I agree that both your proposal and mine are potentially more robust than RI here, since they both change the Finished hash computation for renegotiations even when extensions are *not* sent. > With my proposal, it is also possible for a MITM to alter the handshake= , > but the difference is that the server can prove it happened since neith= er > Finished computation will match. If the server is configured to perform insecure renegotiations, then in your proposal it must accept a client Finished message with the unchanged hash computation. So an attack is certainly possible when the client is unpatched. I'll have to think some more about the security of RI in the fallback case when both client and server are patched (but lenient); it's not at all obvious. >>> This solution is to make available a modified Finished calculation >>> that a patched client can use for all handshakes including the >>> initial one. This solution does not even break compatibility with >>> old clients -- a server would support BOTH the old and the new >>> Finished message computation and do the right thing based on which >>> one was used by the client. >> >> This has a significant disadvantage relative to the RI proposal: >> Consider a patched client that wants to connect to unpatched servers. >> With your suggested approach, such a client must use the old Finished >> message computation on an initial handshake (or else it must add a >> fallback in order to connect to those servers, which is undesirable). >> Therefore, it isn't distinguishable from an unpatched client by >> looking at cleartext handshake messages. >=20 > I'm suggesting to give up cleartext patch status for better attack > detection and better interoperability since there is NO change to bits > on the wire, no need for extensions or even TLS (SSLv3 can be fixed in > exactly the same way). My proposal also fixes the Finished hash computation for SSLv3 in exactly the same way as for TLS. > A server can actually log when neither Finished message calculation > matches and alert the proper people to investigate the attack. Such logging is not particularly useful if the attacker will just avoid attacks that won't work and would be logged. All else being equal, being able to distinguish attacks that failed from interoperability problems would be nice, but it often isn't feasible, and I don't think that's a big problem. >> My proposal of changing the Finished hash computation for renegotiatio= ns >> only, plus sending an empty extension to signal patched status, does n= ot >> have this disadvantage [of not signalling patched status in cleartext]= =2E >> It also does not rely on the extension for anything other than detecti= on >> of patched/unpatched status. >=20 > This has the same problems as RI w.r.t. not being compatible with SSLv3= and > requiring extensions. That is not correct, it is compatible with SSLv3: - If the client is using the lenient policy, then it still SHOULD send the extension, but sending the extension is not *required* -- even on renegotiations, unlike RI. There is no loss of security by not doing so, only a loss of information to the server. The disadvantage to the client of not sending the extension on the initial handshake is that a strictly configured server might refuse to= accept that connection. I wouldn't expect this to be much of a problem= in practice, because that server policy is only tenable in tightly controlled environments where there is an intention to upgrade all clients and servers together, which is rather inconsistent with the assumption that SSLv3 is still in use. (Note: all patched servers would reject connections where they see a renegotiation and the client didn't include the verify_data in the hash. The above stricter policy is only needed to prevent attacks in which an unpatched client sees the renegotiation, and is connecting to a patched server that sees an initial handshake.) - Like RI, it is fully compatible with SSLv3-only servers that are TLS- and extension-tolerant. - Unlike RI, a lenient client that does not send the extension need not support TLS. (I don't think this is really an important advantage in most situations, since almost all software-implemented clients already= support TLS. There might be some SSLv3-only embedded clients where you want an absolutely minimal patch, I suppose.) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig222E6FF343AE8818C2A48F8C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksBFjkACgkQWUc8YzyzqAdJUgD6Azy9G90YfmX3XoYrh+APuZCZ EYZ/FSU8jGKJG13p2vIA/2qMLTuJJn/GyyofoxOO1wWkps4n3ynt1y+3ZN+l+3PV =tmmo -----END PGP SIGNATURE----- --------------enig222E6FF343AE8818C2A48F8C-- From mrex@sap.com Mon Nov 16 02:29:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D4F3A6801 for ; Mon, 16 Nov 2009 02:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=0.561, 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 u-BEm1pRxwaz for ; Mon, 16 Nov 2009 02:29:13 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 478D43A6929 for ; Mon, 16 Nov 2009 02:29:13 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAGAT9GM011383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 11:29:09 +0100 (MET) From: Martin Rex Message-Id: <200911161029.nAGAT8uN019401@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Mon, 16 Nov 2009 11:29:08 +0100 (MET) In-Reply-To: <4B00A722.1020400@pobox.com> from "Michael D'Errico" at Nov 15, 9 05:13:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 10:29:14 -0000 Michael D'Errico wrote: > > > The most simplistic approch to renego protection is > > > > 1. the client signals that it is patched through a fake > > ciphersuite ID in each ClientHello > > > > 2. the client only supports secure renegotiation and > > secure renegotiation is specified to change the definition > > of the handshake message hash for renegotiation handshakes > > to include the verify_data of the client.finished and > > server.finished after the ServerHello. > > No, this does not plug the hole. The magic ciphersuite in (1) > requires that the server recognize it, i.e. it is patched. > Therefore it will not perform insecure renegotiation even > without seeing the ciphersuite (especially without seeing it). Of course the server needs to implement secure renegotiation as well. If the server doesn't want to support old style renegotiation, it doesn't need to look for the ciphersuite ID at all, it can also just perform the new handshake message hash for ever renegotiation handshake. The fake ciphersuite ID is only for the signaling, and the server wants to signal back, re-puposing an existing protocol field of a vanilla ServerHello, then it needs to check whether the client will get the hint and not choke on it. > > And again the client's INITIAL handshake is the one that the > server sees as a renegotiation in Marsh's attack, so the fact > that the client won't REnegotiate (2) is unhelpful; the attack > has already completed. Bugs of the server must be fixed at the server. You can not expect from end users that they will have every piece of TLS client software that they might be using reviewed before the dare touching it. -Martin From mrex@sap.com Mon Nov 16 02:53:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F6028C139 for ; Mon, 16 Nov 2009 02:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.734 X-Spam-Level: X-Spam-Status: No, score=-5.734 tagged_above=-999 required=5 tests=[AWL=0.515, 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 lp3fIf78Zwfr for ; Mon, 16 Nov 2009 02:53:12 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BFFE128C137 for ; Mon, 16 Nov 2009 02:53:11 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAGAr2vD008321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 11:53:02 +0100 (MET) From: Martin Rex Message-Id: <200911161053.nAGAr1DS020959@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joseph Salowey) Date: Mon, 16 Nov 2009 11:53:00 +0100 (MET) In-Reply-To: from "Joseph Salowey" at Nov 15, 9 10:31:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 10:53:12 -0000 Joseph Salowey wrote: > > > > I really like to hear convincing arguments why we need the > > TLS extension in the renegotiation handshake, and why > > changing the definition for the handshake message hash > > instead is not a superior alternative. In particular one > > that will grow naturally into future TLS revisions. > > [Joe] TLS Extensions is the standard way to extend the protocol. Using > the ciphersuite field as a means to change the base protocol is a new > extension mechanism. I don't think this is a particularly good thing > for TLS to grow into. I don't see a reason to define a new extension > mechanism when we can achieve what is necessary using the existing > mechanism. When TLS 1.2+x is defined in the future then it can address > the renegotiation problem as necessary and the version field will signal > the underlying changes. You do not seem to understand the TLS renegotiation problem at all. We are NOT supposed to extend TLSv1.2, we are supposed to FIX all protocol versions of TLS out there SSLv3->TLSv1.2. The TLS extensions mechanism is completely irrelevant to the problem and completely unnecessary for the fix. Requiring people to implement generic TLS extensions, something that was completely undefined even for TLSv1.0 and is still optional in TLSv1.2, only to fix something that has nothing to do with TLS extensions and can be fixed much more easily without TLS extensions is a pretty bad idea and poor engineering. Think about the lines of code for a client: minimum: 1 Memorizing the verify_data from the last finished messages (extend the session structure to keep a copy) 2x memcpy() one after creating client.finished and after verifying server.finished. 2 add the verify_data to the handshake message hash for renego 1x if () plus 2x add_to_handshake_message_hash(previous.verify_data) after processing server hello extra: the handshake 3 add the fake ciphersuite ID to the clients ciphersuite list can be as simple as adding an entry to a statically comiled structure, but 5 statements to add it dynamically is still ok 4 check the ServerHello for the server-signal to decide wether to abort talking to an unpatched server 1x if ( ... server_version ...) { send_alert( ) ; goto error } more extra: still talk to old servers if config permits it 5 config parsing 6 put a second condition into the if() in (2) The TLS extensions stuff requires at least 3x the amount of code, is a complete waste for the code and for the network bandwidth. Just dump the completely unnecessary TLS extension gift wrapping for the fix and get over it. -Martin From ekr@networkresonance.com Mon Nov 16 03:27:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EA53A6958 for ; Mon, 16 Nov 2009 03:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1Db5WCfvnMO for ; Mon, 16 Nov 2009 03:27:29 -0800 (PST) Received: from kilo.networkresonance.com (unknown [194.126.108.9]) by core3.amsl.com (Postfix) with ESMTP id 801BE3A6957 for ; Mon, 16 Nov 2009 03:27:29 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 82CF269F8D7; Mon, 16 Nov 2009 13:28:46 +0200 (EET) Date: Mon, 16 Nov 2009 13:28:45 +0200 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911160036.nAG0atRS014903@fs4113.wdf.sap.corp> References: <200911160036.nAG0atRS014903@fs4113.wdf.sap.corp> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116112846.82CF269F8D7@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 11:27:30 -0000 At Mon, 16 Nov 2009 01:36:55 +0100 (MET), Martin Rex wrote: > > The most simplistic approch to renego protection is > > 1. the client signals that it is patched through a fake > ciphersuite ID in each ClientHello > > 2. the client only supports secure renegotiation and > secure renegotiation is specified to change the definition > of the handshake message hash for renegotiation handshakes > to include the verify_data of the client.finished and > server.finished after the ServerHello. > > Everything else is options for vendors and users. This is an interesting suggestion, but I think it has some problematic aspects. As has been noted several times, if the client desires to guarantee that it does not form connections to unpatched servers, then servers need to behave differently only on the initial connection. Your proposal doesn't accomodate this. Obviously this could be fixed--the natural approach is to modify the server's Finished even on the initial negotiation, but this requires conditional behavior in the Finished processor, which is sort of distressing. The problem becomes even more complicated when we consider resumption. We could use other mechanisms, such as ServerRandom signalling, but we're now at the point where we're generating a lame version of extension signalling using other mechanisms. Absent some evidence that there is a real SSLv3 compatibility issue, I'm not sure why that's a good idea. On an aesthetic level, the TLS handshake hashes are just that, handshake hashes. Injecting new data into that computation doesn't strike me as really that architecturally fantastic an idea. If we were to go down that road, I suspect that Rob Dugal's suggestion of just continuing the handshake hashes would be superior. -Ekr From ekr@networkresonance.com Mon Nov 16 03:33:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC1D3A6906 for ; Mon, 16 Nov 2009 03:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMdXO-Cr-TTD for ; Mon, 16 Nov 2009 03:33:07 -0800 (PST) Received: from kilo.networkresonance.com (unknown [194.126.108.9]) by core3.amsl.com (Postfix) with ESMTP id BA5163A67CF for ; Mon, 16 Nov 2009 03:33:06 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id ED8DA69F8DC; Mon, 16 Nov 2009 13:34:24 +0200 (EET) Date: Mon, 16 Nov 2009 13:34:24 +0200 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911161053.nAGAr1DS020959@fs4113.wdf.sap.corp> References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116113424.ED8DA69F8DC@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 11:33:07 -0000 At Mon, 16 Nov 2009 11:53:00 +0100 (MET), Martin Rex wrote: > > Joseph Salowey wrote: > > > > > > I really like to hear convincing arguments why we need the > > > TLS extension in the renegotiation handshake, and why > > > changing the definition for the handshake message hash > > > instead is not a superior alternative. In particular one > > > that will grow naturally into future TLS revisions. > > > > [Joe] TLS Extensions is the standard way to extend the protocol. Using > > the ciphersuite field as a means to change the base protocol is a new > > extension mechanism. I don't think this is a particularly good thing > > for TLS to grow into. I don't see a reason to define a new extension > > mechanism when we can achieve what is necessary using the existing > > mechanism. When TLS 1.2+x is defined in the future then it can address > > the renegotiation problem as necessary and the version field will signal > > the underlying changes. > > > You do not seem to understand the TLS renegotiation problem at all. > > We are NOT supposed to extend TLSv1.2, we are supposed to FIX > all protocol versions of TLS out there SSLv3->TLSv1.2. Perhaps you should consider that other people have a different view of the problem than you do. In particular, I don't think there is anything like consensus that we need to fix SSLv3, a protocol which was never controlled by IETF--and in fact wasn't even published by it as informational. > Requiring people to implement generic TLS extensions, something > that was completely undefined even for TLSv1.0 and is still optional > in TLSv1.2, Not that it matters, but his is incorrect. TLS 1.2 requires extension processing. See S 7.4.1 of RFC 5246: Servers MUST NOT send this extension. TLS servers MUST support receiving this extension. > only to fix something that has nothing to do with > TLS extensions and can be fixed much more easily without TLS extensions > is a pretty bad idea and poor engineering. You're entitled to your opinion, of course, but I'm unconvinced. > Think about the lines of code for a client: I don't agree with your analysis of code complexity, but even if you were correct the implementation effort is in any case so minimal compared to the size of the deployment problem that it strikes me as largely irrelevant. Moreover, we already have implementations of RI, so the marginal implementation effort is even lower compared to doing something new. -Ekr From mrex@sap.com Mon Nov 16 06:05:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D59A3A6953 for ; Mon, 16 Nov 2009 06:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.475, 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 oiEQu2rpHelY for ; Mon, 16 Nov 2009 06:05:39 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 485653A68B9 for ; Mon, 16 Nov 2009 06:05:39 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAGE5Yfi011420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 15:05:34 +0100 (MET) From: Martin Rex Message-Id: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 16 Nov 2009 15:05:31 +0100 (MET) In-Reply-To: <20091116113424.ED8DA69F8DC@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 01:34:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:05:40 -0000 Eric Rescorla wrote: > > Martin Rex wrote: > > > > Requiring people to implement generic TLS extensions, something > > that was completely undefined even for TLSv1.0 and is still optional > > in TLSv1.2, > > Not that it matters, but his is incorrect. TLS 1.2 requires extension > processing. See S 7.4.1 of RFC 5246: > > Servers MUST NOT send this extension. TLS servers MUST support > receiving this extension. You're refering to the signature algorithms extensions, which clients MUST NOT send if they're offering to talk TLSv1.1? OK, I wasn't aware of that. Count the servers on the Internet that support TLSv1.2 today with your left hand and substract them for the rest of the servers out there. Do you realize how much implementation and testing is involved when shipping the fix as a TLS extension. If someone with an old server, who doesn't implement renegotiation and TLS extensions wants to add this patch, he will need to add the entire TLS extensions handling in a generic fashion and require a significantly larger interop testing scenario to make sure that it acutally works: 1. client without Extensions 2. client with 1 Extension no RI 3. client with 1 Extension RI 4a. client with 2 Extensions RI as first 4b. client with 2 Extensions RI as 2nd 5a. client with 3 Extensions RI as first 5b. client with 3 Extensions RI as 2nd 5c. client with 3 Extensions RI as 3rd So that means that poor server maintainer will also have to build a client with all that stuff in order to test whether the server implementation is correct. Compare this to the extension less approach: 1. client without patch 2. client with patch and all he needs to check is whether the signaling works. > > > Think about the lines of code for a client: > > I don't agree with your analysis of code complexity, but even if > you were correct the implementation effort is in any case so > minimal compared to the size of the deployment problem > that it strikes me as largely irrelevant. Moreover, we already > have implementations of RI, so the marginal implementation > effort is even lower compared to doing something new. You're going to waste network bandwith eternally in a completely useless fashion. So you want the IETF to rubber-stamp an obviously inferior approach because you prefered to come up with a solution in secret? -Martin From mrex@sap.com Mon Nov 16 06:20:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A74C3A6AA3 for ; Mon, 16 Nov 2009 06:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_CODEINE=0.833] 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 9VT3bc0Lk0Nq for ; Mon, 16 Nov 2009 06:20:15 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 91CFE3A6978 for ; Mon, 16 Nov 2009 06:20:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAGEKDQV018115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 15:20:13 +0100 (MET) From: Martin Rex Message-Id: <200911161420.nAGEK0r0002918@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 16 Nov 2009 15:20:00 +0100 (MET) In-Reply-To: <20091116113424.ED8DA69F8DC@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 01:34:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:20:17 -0000 Eric Rescorla wrote: > > I don't agree with your analysis of code complexity, but even if > you were correct the implementation effort is in any case so > minimal compared to the size of the deployment problem > that it strikes me as largely irrelevant. Moreover, we already > have implementations of RI, so the marginal implementation > effort is even lower compared to doing something new. There is obviously no surprise that those who have already implemented this proposal in secret have a bias towards using it. Most of them are actually affected by the problem, because they offered TLS renegotiation on the server side. Please consider that you are asking a lot of other implementors, who do not have an implementation yet, and many of which are not actually vulnerable to the problem, to implement this. For them, the difference between a TLS extension RI and a much smaller and more efficient extension-less solution can be very significant -- in particular when it comes to testing the server-side of the generic extensions handling. The amount of code changes for the extension-less solution is rather small, this is _NOT_ going to be a burden for the implementors that have experimenting with TLS extension RI. It will be LESS than a day of work for each codeline. Offering UIs or APIs to configure policy is more than 10x the effort than implementing the actual protocol fix (which, as I said, is basically the same as the TLS extension RI, just without the superfluous TLS extension wrapping). And that policy configuration stuff will work equally well for both. -Martin From ekr@networkresonance.com Mon Nov 16 06:31:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E633C3A6AA1 for ; Mon, 16 Nov 2009 06:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2Ne4vhhEcLy for ; Mon, 16 Nov 2009 06:31:09 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id B9AA93A681D for ; Mon, 16 Nov 2009 06:31:08 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1NA2bj-0004k3-00 for tls@ietf.org; Mon, 16 Nov 2009 16:31:07 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 7704B69F984; Mon, 16 Nov 2009 16:32:25 +0200 (EET) Date: Mon, 16 Nov 2009 16:32:24 +0200 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp> References: <20091116113424.ED8DA69F8DC@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116143225.7704B69F984@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:31:10 -0000 At Mon, 16 Nov 2009 15:05:31 +0100 (MET), Martin Rex wrote: > Eric Rescorla wrote: > > > Think about the lines of code for a client: > > > > I don't agree with your analysis of code complexity, but even if > > you were correct the implementation effort is in any case so > > minimal compared to the size of the deployment problem > > that it strikes me as largely irrelevant. Moreover, we already > > have implementations of RI, so the marginal implementation > > effort is even lower compared to doing something new. > > You're going to waste network bandwith eternally in a completely > useless fashion. This strikes me as a fairly unconvincing objection. The average TLS handshake consumes something like 1+ KB. This extension consumes something like 45 bytes. Given that when we did TLS 1.1 added 16 bytes to every single CBC datagram, I'm having trouble getting worked up about the additional overhead. > So you want the IETF to rubber-stamp an obviously inferior approach > because you prefered to come up with a solution in secret? No, thats not what I want. (1) It's your opinion that this is "obviously inferior". I don't agree, for reasons I've already indicated. (2) I didn't prefer to come up with a solution in secret. I was informed of this issue in secret, worked with others to develop a fix, and then submitted it to the IETF for public review and comment. What, exactly, is it you think I did that was inappropriate, bearing in mind that I was informed of the issue under NDA? More generally, I appreciate that you feel that you're technically right and others are wrong, but I'd ask you to remember that others may have come to other conclusions and that it doesn't really help to imply as you do above that they're acting in bad faith. -Ekr From ekr@networkresonance.com Mon Nov 16 06:35:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBBE3A6AA3 for ; Mon, 16 Nov 2009 06:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_OBFU_CODEINE=0.833] 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 3fib2wKIkSor for ; Mon, 16 Nov 2009 06:35:50 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 1439028C103 for ; Mon, 16 Nov 2009 06:35:50 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1NA2gG-0006Ga-00 for tls@ietf.org; Mon, 16 Nov 2009 16:35:48 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 737C869F989; Mon, 16 Nov 2009 16:37:09 +0200 (EET) Date: Mon, 16 Nov 2009 16:37:09 +0200 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911161420.nAGEK0r0002918@fs4113.wdf.sap.corp> References: <20091116113424.ED8DA69F8DC@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116143709.737C869F989@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:35:51 -0000 At Mon, 16 Nov 2009 15:20:00 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > I don't agree with your analysis of code complexity, but even if > > you were correct the implementation effort is in any case so > > minimal compared to the size of the deployment problem > > that it strikes me as largely irrelevant. Moreover, we already > > have implementations of RI, so the marginal implementation > > effort is even lower compared to doing something new. > > There is obviously no surprise that those who have already implemented > this proposal in secret have a bias towards using it. Most of them > are actually affected by the problem, because they offered TLS > renegotiation on the server side. Well, I don't know who "most of them" you're talking about is. I did the original cut of the OpenSSL implementation and it's not like I operate a service that relies on TLS server-side renegotiation. I just thought it would be a public service to write the code. I'm sorry if that offends you. > Please consider that you are asking a lot of other implementors, > who do not have an implementation yet, and many of which are not > actually vulnerable to the problem, to implement this. I'm not saying any such thing. If you're not willing to do server side renegotiation I think it's perfectly appropriate to make no changes to your implementation. > For them, the difference between a TLS extension RI and a much > smaller and more efficient extension-less solution can be > very significant -- in particular when it comes to testing > the server-side of the generic extensions handling. > > > The amount of code changes for the extension-less solution is > rather small, this is _NOT_ going to be a burden for the > implementors that have experimenting with TLS extension RI. > It will be LESS than a day of work for each codeline. Yes, as I said above I consider the entire implementation effort issue to be a complete red herring. I was merely observing that if one takes it seriously it's not clear that it actually cuts in the direction you are arguing. -Ekr From mrex@sap.com Mon Nov 16 08:53:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7663A6AE0 for ; Mon, 16 Nov 2009 08:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.81 X-Spam-Level: X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=0.439, 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 T99Ve9YmL4Uh for ; Mon, 16 Nov 2009 08:53:05 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 686A83A6AC9 for ; Mon, 16 Nov 2009 08:53:05 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAGGr2xM020180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 17:53:02 +0100 (MET) From: Martin Rex Message-Id: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 16 Nov 2009 17:53:01 +0100 (MET) In-Reply-To: <20091116055101.9D38969F87F@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 07:51:01 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:53:06 -0000 Eric Rescorla wrote: > > > What worries me are deployments like [all the parking meters and traffic > > lights in ]. > > > > Or look at all the little plastic boxes returned from searches like this: > > http://search.hp.com/query.html?qt=ssl/tls > > And what fraction of those devices will patch at all? And this is why it is very important that we can signal on ALL future TLS connections established by a client, so that a MITM can not FORCE an updated, but backwards compatible client to renegotiate insecurely with an updated, but backwards compatible server. This is what the TLS extensions RI currently fails completely. About the deployment data: I have just made a couple of checks and here are my results: I checked the following Microsoft platforms: MSIE6 on WinXP MSIE7 on WinXP MSIE6 on WinXPpro 64-bit (equal Windows 2003 64-bit) MSIE8 on WinXPpro 64-bit (equal Windows 2003 64-bit) MSIE7 on Windows2008sp1 Server On all of these, SSLv3 protocol was configured in the internet options, and when SSLv3 is configured, none of the above MSIE Browsers would send a TLS extension in ClientHello. When I disabled SSLv3 support in the Intenet Options, only MSIE7 on Vista started sending TLS extensions, neither of MSIE6/7/8 on XP and XPpro64/Windows2003 sends extensions. I wasn't able to get Firefox 3.0.15 sending TLS extension, even when switching off SSLv3 support. I noticed that Firefox 3.5.5 sends TLS extensions on the first connect, and will fallback automatically to a SSLv3-with-SSLv2 ClientHello Handshake if the Server rejects the request. So I'm wondering about the following: Is Microsoft really eager to ship a hotfix for WinXP and Win2K3 that makes all MSIE-Version send a TLS extension? It seems that such behaviour is completely untested in the majority of installations of Microsoft software. And does Microsoft really want to backport TLS extensions into WinXP and Win2K3 so badly _AND_ right now -- although we could easily devise a _MUCH_ smaller fix entirely without TLS extensions. What the TLS WG ought to provide is a fix that runs smoothly with all of the backwards-compatible extension-less handshakes so that it can be enabled for whatever backwards compatibility requirements that customers might have. As I said, it is extremely valuable to get the renegotiation protection IMMEDIATELY for all modes of operation with extremely little probability of breaking anything as soon as the client and the server are patched. There WILL be a transistion period, and the TLS extension RI will cause all updated clients with an automatic fallback or with interop requirements for old components vulnerable to the problem. -Martin From marsh@extendedsubset.com Mon Nov 16 09:03:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0E528C19F for ; Mon, 16 Nov 2009 09:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.471, 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 dCgrCrS4Ta2Z for ; Mon, 16 Nov 2009 09:03:28 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id BC85A28C19C for ; Mon, 16 Nov 2009 09:03:28 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NA4z8-000025-HP; Mon, 16 Nov 2009 17:03:26 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AF323667C; Mon, 16 Nov 2009 17:03:22 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19wsyJeudXf5bsxqUy3bBXY5uL0g4mNIzI= Message-ID: <4B0185D8.70204@extendedsubset.com> Date: Mon, 16 Nov 2009 11:03:20 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp> In-Reply-To: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 17:03:29 -0000 Martin Rex wrote: > > So you want the IETF to rubber-stamp an obviously inferior approach > because you prefered to come up with a solution in secret? That is being unfair. It was not EKR's decision to work on a fix in secret, it was mine and Steve Dispensa's. We thought that we would have a better chance at presenting a good fix for the bug along side its disclosure if we brought some of the relevant engineering types together at the beginning of the process. We did tentatively agree on a proposal for an Internet Draft in secret, and now we are seeing the limitations of that approach. It would not have been anyone's first choice, least of all EKR's. - Marsh From ekr@networkresonance.com Mon Nov 16 09:11:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B370628C197 for ; Mon, 16 Nov 2009 09:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey+NcmjTTEjF for ; Mon, 16 Nov 2009 09:11:29 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 5B3763A6AD5 for ; Mon, 16 Nov 2009 09:11:29 -0800 (PST) Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1NA56t-0002Z3-00 for tls@ietf.org; Mon, 16 Nov 2009 19:11:27 +0200 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 772ED69F9E5; Mon, 16 Nov 2009 19:12:46 +0200 (EET) Date: Mon, 16 Nov 2009 19:12:45 +0200 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> References: <20091116055101.9D38969F87F@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091116171246.772ED69F9E5@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 17:11:30 -0000 At Mon, 16 Nov 2009 17:53:01 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > > What worries me are deployments like [all the parking meters and traffic > > > lights in ]. > > > > > > Or look at all the little plastic boxes returned from searches like this: > > > http://search.hp.com/query.html?qt=ssl/tls > > > > And what fraction of those devices will patch at all? > > And this is why it is very important that we can signal on ALL > future TLS connections established by a client, so that a MITM > can not FORCE an updated, but backwards compatible client to > renegotiate insecurely with an updated, but backwards compatible server. > This is what the TLS extensions RI currently fails completely. I don't agree with this claim. A client which sends RI only on renegotiation and aborts the connection if it does not receive RI in return does not have this problem. > About the deployment data: > > I have just made a couple of checks and here are my results: > > I checked the following Microsoft platforms: > MSIE6 on WinXP > MSIE7 on WinXP > MSIE6 on WinXPpro 64-bit (equal Windows 2003 64-bit) > MSIE8 on WinXPpro 64-bit (equal Windows 2003 64-bit) > MSIE7 on Windows2008sp1 Server > > On all of these, SSLv3 protocol was configured in the internet options, > and when SSLv3 is configured, none of the above MSIE Browsers would > send a TLS extension in ClientHello. > > When I disabled SSLv3 support in the Intenet Options, only > MSIE7 on Vista started sending TLS extensions, > neither of MSIE6/7/8 on XP and XPpro64/Windows2003 sends extensions. > > > I wasn't able to get Firefox 3.0.15 sending TLS extension, > even when switching off SSLv3 support. > > I noticed that Firefox 3.5.5 sends TLS extensions on the first connect, > and will fallback automatically to a SSLv3-with-SSLv2 ClientHello Handshake > if the Server rejects the request. > > > So I'm wondering about the following: > > Is Microsoft really eager to ship a hotfix for WinXP and Win2K3 that > makes all MSIE-Version send a TLS extension? It seems that such > behaviour is completely untested in the majority of installations > of Microsoft software. > > And does Microsoft really want to backport TLS extensions into > WinXP and Win2K3 so badly _AND_ right now -- although we could > easily devise a _MUCH_ smaller fix entirely without TLS extensions. Again, I think this _MUCH_ smaller claim is unconvincing. The implementation effort is trivial in either case. In fact, arguably RI is a smaller fix since it uses standard and well understood TLS code paths, whereas the fix you propose involves somehow injecting data into the handshake hashes in the middle. > As I said, it is extremely valuable to get the renegotiation protection > IMMEDIATELY for all modes of operation with extremely little probability > of breaking anything as soon as the client and the server are patched. > > There WILL be a transistion period, and the TLS extension RI will > cause all updated clients with an automatic fallback or with > interop requirements for old components vulnerable to the problem. Again, I don't agree with this claim if you only send the extension on rehandshake. -Ekr From mrex@sap.com Mon Nov 16 09:25:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB5B28C1D2 for ; Mon, 16 Nov 2009 09:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.837 X-Spam-Level: X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=0.412, 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 uOwFUg4ZKEQI for ; Mon, 16 Nov 2009 09:25:42 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A3DA828C1D1 for ; Mon, 16 Nov 2009 09:25:38 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAGHPXDC000532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 18:25:33 +0100 (MET) From: Martin Rex Message-Id: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Mon, 16 Nov 2009 18:25:32 +0100 (MET) In-Reply-To: <4B0185D8.70204@extendedsubset.com> from "Marsh Ray" at Nov 16, 9 11:03:20 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 17:25:43 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > > > So you want the IETF to rubber-stamp an obviously inferior approach > > because you prefered to come up with a solution in secret? > > That is being unfair. > > It was not EKR's decision to work on a fix in secret, it was mine and > Steve Dispensa's. We thought that we would have a better chance at > presenting a good fix for the bug along side its disclosure if we > brought some of the relevant engineering types together at the beginning > of the process. > > We did tentatively agree on a proposal for an Internet Draft in secret, > and now we are seeing the limitations of that approach. It would not > have been anyone's first choice, least of all EKR's. It is _not_ my intention to critizise that people develop ideas or protocols outside of the IETF (open or closed group) and then come to the IETF for standardization. That's actually quite common and not a problem. But when a proposal enters the IETF process, the IETF and the working group should discuss it based on its technical merits. I'm getting the impression that the technical merit is not getting the attention that it deserves. TLS extensions are evidently largely untested in the installed base. The majority of the installed clients does _NOT_ send it, and those clients that have started sending it, apparently didn't dare to do this without an automatic fallback. Having to retrofit the TLS extensions in a generic fashion into SSLv3 and TLSv1.0 servers is a completely unnecessary and trivially avoidable roadblock for maintainers. And it doesn't seem to be to leave the fallbacks or SSLv3-compatibility options that exist in current Browsers completely out in the rain, where we could also trivially cover those scenarious with the smaller and easier-to-implement extension-less approach. Considering the urgency of the problem, now is a particularly bad time to begin gathering interop experience with TLS extensions, given that TLS WG didn't care about them for years. To me, it looks like the REAL problems with the installed base described in draft-pettersen-tls-interop-experience-00.txt (June 2006 !) didn't result in any significant actions by the TLS WG to improve this, let alone determine the scope and severity of the problems. Quoting Section 6. of draft-pettersen-tls-interop-experience-00.txt 6. Consequences As a consequence of the problems detailed above, many mass-market client vendors have had to deploy SSL/TLS implementations that disable protocol features if the server does not understand it. In particular, this was necessary both for the move to TLS 1.0, and to TLS 1.1, but it has also become necessary for TLS Extensions. -Martin From uri@ll.mit.edu Mon Nov 16 09:32:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798E53A6997 for ; Mon, 16 Nov 2009 09:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPbr5s3GVlgA for ; Mon, 16 Nov 2009 09:32:33 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 8FCF33A67F6 for ; Mon, 16 Nov 2009 09:32:33 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAGHWT4Y014527 for ; Mon, 16 Nov 2009 12:32:29 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAGAaOJI; Mon Nov 16 12:12:13 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Mon, 16 Nov 2009 12:12:13 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "tls@ietf.org" Date: Mon, 16 Nov 2009 12:12:10 -0500 Thread-Topic: [TLS] simplistic renego protection Thread-Index: Acpm3q2kmFRpWJ1TSvyigkTUxSFFKwAAUDz9 Message-ID: In-Reply-To: <4B0185D8.70204@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 17:32:34 -0000 I thought it was the preferred IETF approach to implement a proposal before moving it forward?=20 On 11/16/09 12:03 , "Marsh Ray" wrote: > Martin Rex wrote: >>=20 >> So you want the IETF to rubber-stamp an obviously inferior approach >> because you prefered to come up with a solution in secret? >=20 > That is being unfair. >=20 > It was not EKR's decision to work on a fix in secret, it was mine and > Steve Dispensa's. We thought that we would have a better chance at > presenting a good fix for the bug along side its disclosure if we > brought some of the relevant engineering types together at the beginning > of the process. >=20 > We did tentatively agree on a proposal for an Internet Draft in secret, > and now we are seeing the limitations of that approach. It would not > have been anyone's first choice, least of all EKR's. >=20 > - Marsh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 Regards, Uri From mike-list@pobox.com Mon Nov 16 09:55:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780DF3A6AF1 for ; Mon, 16 Nov 2009 09:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 fyXADAV6rncn for ; Mon, 16 Nov 2009 09:55:14 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 879DF3A697A for ; Mon, 16 Nov 2009 09:55:14 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 556749FE9A for ; Mon, 16 Nov 2009 12:55:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=cDPN+pNxNO1Q Atah+J45PwzHkN0=; b=K3lY2tJYMFAW1YQ63Nf/+N2b1hJeTJgB4h+eIw7lAKVs nF3PEXVIOgRpKxvKEE9iDZbFww4mt25+2vRrGcOfUhMTKcxc3KIbMJUFcCGPWJEd 4eLU40R5kExWdloIgez3Z+2TtlTbpYp3jpk7P/iqToz8za/AhybvTtcH93FamRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=K6Dqd/ 1NXzlSUuBM8lGmDFS0Vo+jKQVSFmiTvLWJ8x8yIK9sdqpa0lFNs1uwF+0s72wgd4 qgA9awutc89lqgcnU4YIQTwEWpoN7/aXIXThgpSO97FxssFZ/CXtPy7nky2xOq6r cAK4yqUSQnfaDvjXjsRN18fTfwKvhI1vopn/A= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 525159FE99 for ; Mon, 16 Nov 2009 12:55:13 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 011B79FE98 for ; Mon, 16 Nov 2009 12:55:12 -0500 (EST) Message-ID: <4B01923F.9020806@pobox.com> Date: Mon, 16 Nov 2009 09:56:15 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911161029.nAGAT8uN019401@fs4113.wdf.sap.corp> In-Reply-To: <200911161029.nAGAT8uN019401@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 309BB89E-D2D9-11DE-91C3-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 17:55:15 -0000 >> And again the client's INITIAL handshake is the one that the >> server sees as a renegotiation in Marsh's attack, so the fact >> that the client won't REnegotiate (2) is unhelpful; the attack >> has already completed. > > Bugs of the server must be fixed at the server. You can not expect > from end users that they will have every piece of TLS client software > that they might be using reviewed before the dare touching it. I don't know where you got the idea I was talking about buggy servers. The attack requires that there be a man-in-the-middle between the client and server. The MITM handshakes once with the server. The client then handshakes with the server via the MITM, so: - the client sees the handshake as its initial handshake - the server sees the handshake as a renegotiation This is the point: the client is attacked on its *initial* handshake. Therefore the client needs to be protected on its *initial* handshake. It doesn't matter what happens after that. If the client has completed its initial handshake and there was no MITM, it is impossible for a MITM to insert itself in the next handshake (i.e. a renegotiation). So from the client's point of view the only handshake it needs to be concerned with (in terms of security not mechanics) is the initial one. Mike From mrex@sap.com Mon Nov 16 10:03:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080C83A6897 for ; Mon, 16 Nov 2009 10:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.388, 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 3YlLJ4Y1U0HA for ; Mon, 16 Nov 2009 10:03:28 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BAFC03A67D9 for ; Mon, 16 Nov 2009 10:03:27 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAGI3KG8014501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 19:03:20 +0100 (MET) From: Martin Rex Message-Id: <200911161803.nAGI3JMF016194@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 16 Nov 2009 19:03:19 +0100 (MET) In-Reply-To: <20091116171246.772ED69F9E5@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 07:12:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:03:29 -0000 Eric Rescorla wrote: > > > Eric Rescorla wrote: > > > > > > > What worries me are deployments like [all the parking meters and traffic > > > > lights in ]. > > > > > > > > Or look at all the little plastic boxes returned from searches like this: > > > > http://search.hp.com/query.html?qt=ssl/tls > > > > > > And what fraction of those devices will patch at all? And what is your suggestion? Enforce the client policy to not fallback to extension-less ClientHello and BRICK all those devices? Or suggest Browsers and TLS client to allow or implement an app-level fallback to extension-less Client-Hello, but keep a list of servers for which to allow this, because you want to deny them any protection for that communication? > > > And this is why it is very important that we can signal on ALL > > future TLS connections established by a client, so that a MITM > > can not FORCE an updated, but backwards compatible client to > > renegotiate insecurely with an updated, but backwards compatible server. > > This is what the TLS extensions RI currently fails completely. > > I don't agree with this claim. > > A client which sends RI only on renegotiation and aborts the > connection if it does not receive RI in return does not > have this problem. A client that is in backwards compatible mode or automatic fallback to extensionless ClientHello will continue to be susceptible to a MITM with a server that is in backwards compatible mode. That is a REAL problem, and it will persist through the transition/migration period. extension-less, it can be entirely avoided. The RI for renegotiation is a completely unnecessary waste. Both peers have all the data they need. > > Again, I think this _MUCH_ smaller claim is unconvincing. The > implementation effort is trivial in either case. In fact, arguably RI > is a smaller fix since it uses standard and well understood TLS code > paths, whereas the fix you propose involves somehow injecting data > into the handshake hashes in the middle. Come on! I thought you looked at OpenSSL and realized how trivial it would be to add the verify_data into the handshake hashes. Adding them as a TLS extensions into the handshake messages requires significantly more code changes. I just looked at OpenSSL 0.9.8g sources, and what I see does not look quite like rocket science: Server Side: s3_srvr.c:ssl3_send_server_hello() return(ssl3_do_write(s,SSL3_RT_HANDSHAKE)); would have to be change to something like: ret = ssl3_do_write(s,SSL3_RT_HANDSHAKE); if ( ret>0 && s->s3->renegotiate ) { /* add previous verify_data of client.finished */ ssl3_finish_mac(s,s->s3->peer_finished_md, s->s3->peer_finished_md_len); /* add previous verify_data of server.finished */ ssl3_finish_mac(s,s->s3->finished_md, s->s3->finished_md_len); } (you will need to copy the finished_md fields to the connection state anyway). > > > As I said, it is extremely valuable to get the renegotiation protection > > IMMEDIATELY for all modes of operation with extremely little probability > > of breaking anything as soon as the client and the server are patched. > > > > There WILL be a transistion period, and the TLS extension RI will > > cause all updated clients with an automatic fallback or with > > interop requirements for old components vulnerable to the problem. > > Again, I don't agree with this claim if you only send the extension on > rehandshake. On the renegotiation handshake the TLS extension is pure waste. And changing only the renegotiation handshake doesn't cover the fallback scenarios and doesn't let the client figure out the server's patch status on initial connect (and neither can the firewall/intrusion detection systems do any checks). -Martin From marsh@extendedsubset.com Mon Nov 16 10:04:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCAC3A6988 for ; Mon, 16 Nov 2009 10:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.438, 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 1ZS7454+6FAW for ; Mon, 16 Nov 2009 10:04:43 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id EE9133A6AE0 for ; Mon, 16 Nov 2009 10:04:42 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NA5wP-0000bp-Ev for tls@ietf.org; Mon, 16 Nov 2009 18:04:41 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 871A3667C for ; Mon, 16 Nov 2009 18:04:40 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+UtdPPrAi8itW7FmgRezfQvwnTkqnVzdo= Message-ID: <4B019434.9020001@extendedsubset.com> Date: Mon, 16 Nov 2009 12:04:36 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls >> \"tls@ietf.org\"" References: <200911161029.nAGAT8uN019401@fs4113.wdf.sap.corp> <4B01923F.9020806@pobox.com> In-Reply-To: <4B01923F.9020806@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:04:43 -0000 Michael D'Errico wrote: > > The attack requires that there be a man-in-the-middle between the > client and server. The MITM handshakes once with the server. The > client then handshakes with the server via the MITM, so: > > - the client sees the handshake as its initial handshake > - the server sees the handshake as a renegotiation > > This is the point: the client is attacked on its *initial* handshake. > > Therefore the client needs to be protected on its *initial* handshake. > > It doesn't matter what happens after that. If the client has completed > its initial handshake and there was no MITM, it is impossible for a MITM > to insert itself in the next handshake (i.e. a renegotiation). So from > the client's point of view the only handshake it needs to be concerned > with (in terms of security not mechanics) is the initial one. I hear this often enough that I don't argue with it every time, nevertheless... There is another attack which is a mirror-image of this one, where the client sees a renegotiation but the server only sees one session. One may dismiss this attack with the reasoning that "well it's the client's fault for not checking the cert at the right point". Perhaps for some specific protocol on TLS that may be true, but there doesn't appear to be anything the TLS protocol itself that requires clients to authenticate (rather than the other way round). I strongly suspect many actual client applications are vulnerable to this attack. For these reasons, I suggest that we are unsafe in concluding that all vulnerabilities can be fixed at the server. - Marsh From mike-list@pobox.com Mon Nov 16 10:27:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311633A69B8 for ; Mon, 16 Nov 2009 10:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 cPXR5dVs-kEt for ; Mon, 16 Nov 2009 10:27:46 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 41B3A3A6938 for ; Mon, 16 Nov 2009 10:27:45 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id DA30B9D211 for ; Mon, 16 Nov 2009 13:27:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=YVDVkdxFyeKt EAkXG0ng9vihnSM=; b=To6PgM+h1hzSE0/PqgdCdxZaEMDfk9F1ho0wZi+HNn97 BK95ieq5ttMVu5W60J+M4cHiMGrT//Uus8z41ycB9x/gJaEABYUBNIO+iiDeEfyd 6JbqDtXK1wCNNEJw/KT+BQgr9BOOPuVSRHhE95PL4rzmAnPH/qwTplTPoW5LODU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=caC5EE iLKg8Xyy2m4aDHPN0b3B7kyPehfNKg0mLwl43Z1MsBW6fR267/KuEaoImtPkfbFH 8Np/H+TKPCqJNyrIxBiI+qIl7Mrafdx2/QO9UHrE0vSpjpxoAn7sa1izbaZWKIfr 7kYr7GXIVbUdqRulz31Cq1ART/sQWejlOQp3o= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D7A0C9D20F for ; Mon, 16 Nov 2009 13:27:43 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 73B8D9D20E for ; Mon, 16 Nov 2009 13:27:43 -0500 (EST) Message-ID: <4B0199DD.5080904@pobox.com> Date: Mon, 16 Nov 2009 10:28:45 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <20091116055101.9D38969F87F@kilo.networkresonance.com> <20091116171246.772ED69F9E5@kilo.networkresonance.com> In-Reply-To: <20091116171246.772ED69F9E5@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: BB394030-D2DD-11DE-B14D-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:27:47 -0000 > A client which sends RI only on renegotiation and aborts the > connection if it does not receive RI in return does not > have this problem. You do not appear to fully understand the attack. It is completely unnecessary for a client to abort a renegotiation. There is no possible man-in-the-middle. This is guaranteed when the client has verified the server's certificate in its initial handshake. Otherwise ALL of TLS would be broken. Now, it is necessary for a client to use whatever-the-fix-is when renegotiating so that the *server* can check for insecure renegotiation, but this is purely mechanical to the client. Mike From mike-list@pobox.com Mon Nov 16 10:35:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7289A3A69BA for ; Mon, 16 Nov 2009 10:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 o14XMws2JcnJ for ; Mon, 16 Nov 2009 10:35:58 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 6AA5E3A6AF4 for ; Mon, 16 Nov 2009 10:35:58 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 8E3CE9D2E3 for ; Mon, 16 Nov 2009 13:35:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=PfV+Nlu1NG2p 0I9lDIYyS5O8Diw=; b=IS41ReoCqwMPREgBRh1lbLMPzvrSjLwrShTAEjgno5GZ u5ob9U43TFmi8W5r3ldA16Z//YsE62TkicbvYvuBL6uYHW9dVrFN8OEQ/4mOGKyF 6cdED5DVNFpWYNu0bkvO+5tHZpAHqVJnmPxiXRvfseN9lIJKHxqBPIlQG/zYLvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ZsHtr5 3KNLXR8aJ1t2aUzsg40S0w3dIbqYzqzMYMamOT1HNYG8SAFztBKSQuJ8ElXpEtOJ 4Ei89A/mnjmOvLomIvInKPpik1pfrzSRWSd3Pm8tMpRsFoEHZOkY5RugCDfm7sye t8W/+Bn8WcjavPNf+sJFlJnDzH7oTeXwrFEd8= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 8B6469D2E2 for ; Mon, 16 Nov 2009 13:35:57 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 0767D9D2E1 for ; Mon, 16 Nov 2009 13:35:55 -0500 (EST) Message-ID: <4B019BC7.2080201@pobox.com> Date: Mon, 16 Nov 2009 10:36:55 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911161029.nAGAT8uN019401@fs4113.wdf.sap.corp> <4B01923F.9020806@pobox.com> <4B019434.9020001@extendedsubset.com> In-Reply-To: <4B019434.9020001@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E17BC7BC-D2DE-11DE-891E-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:35:59 -0000 If a client doesn't check the server's certificate, it is subject to any man-in-the-middle attack. One of the requirements is that a client verify the certificate. If a client doesn't do that, how can we possibly protect it??? I'm interested in providing the best defense to a client that is aware of the MITM renegotiation problem when faced with having to interact with possibly-unpatched servers. Mike Marsh Ray wrote: > Michael D'Errico wrote: >> The attack requires that there be a man-in-the-middle between the >> client and server. The MITM handshakes once with the server. The >> client then handshakes with the server via the MITM, so: >> >> - the client sees the handshake as its initial handshake >> - the server sees the handshake as a renegotiation >> >> This is the point: the client is attacked on its *initial* handshake. >> >> Therefore the client needs to be protected on its *initial* handshake. >> >> It doesn't matter what happens after that. If the client has completed >> its initial handshake and there was no MITM, it is impossible for a MITM >> to insert itself in the next handshake (i.e. a renegotiation). So from >> the client's point of view the only handshake it needs to be concerned >> with (in terms of security not mechanics) is the initial one. > > I hear this often enough that I don't argue with it every time, > nevertheless... > > There is another attack which is a mirror-image of this one, where the > client sees a renegotiation but the server only sees one session. > > One may dismiss this attack with the reasoning that "well it's the > client's fault for not checking the cert at the right point". Perhaps > for some specific protocol on TLS that may be true, but there doesn't > appear to be anything the TLS protocol itself that requires clients to > authenticate (rather than the other way round). > > I strongly suspect many actual client applications are vulnerable to > this attack. > > For these reasons, I suggest that we are unsafe in concluding that all > vulnerabilities can be fixed at the server. > > - Marsh From mrex@sap.com Mon Nov 16 10:44:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26AA528C1F2 for ; Mon, 16 Nov 2009 10:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.366, 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 bm4QbrSmukb7 for ; Mon, 16 Nov 2009 10:44:40 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 71BDE28C1EE for ; Mon, 16 Nov 2009 10:44:39 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAGIiaRK018842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 19:44:36 +0100 (MET) From: Martin Rex Message-Id: <200911161844.nAGIiZtw019142@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Mon, 16 Nov 2009 19:44:35 +0100 (MET) In-Reply-To: <4B0199DD.5080904@pobox.com> from "Michael D'Errico" at Nov 16, 9 10:28:45 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:44:41 -0000 Michael D'Errico wrote: > > > A client which sends RI only on renegotiation and aborts the > > connection if it does not receive RI in return does not > > have this problem. > > You do not appear to fully understand the attack. It is completely > unnecessary for a client to abort a renegotiation. There is no > possible man-in-the-middle. This is guaranteed when the client has > verified the server's certificate in its initial handshake. > Otherwise ALL of TLS would be broken. > > Now, it is necessary for a client to use whatever-the-fix-is when > renegotiating so that the *server* can check for insecure > renegotiation, but this is purely mechanical to the client. I really would appreciate an extension-less negotiation through ClientHello+ServerHello where the Server can confirm to the client that it will do the modified finished calculation on renegotiations, so that the client knows that its initial handshake can not be proxied into the reneogotiation of a server (will fail the finished mac if done). -Martin From bmoeller@acm.org Mon Nov 16 10:49:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35BC3A69E9 for ; Mon, 16 Nov 2009 10:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.009 X-Spam-Level: X-Spam-Status: No, score=-102.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 13Z7QVx1CNNv for ; Mon, 16 Nov 2009 10:49:44 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id C66F13A69E5 for ; Mon, 16 Nov 2009 10:49:43 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LckOB-1NtMwU35RX-00jlGm; Mon, 16 Nov 2009 19:49:36 +0100 From: Bodo Moeller To: Eric Rescorla In-Reply-To: <20091116171246.772ED69F9E5@kilo.networkresonance.com> References: <20091116055101.9D38969F87F@kilo.networkresonance.com> <20091116171246.772ED69F9E5@kilo.networkresonance.com> Message-Id: <9549316B-6B6F-4599-B61A-1B62D7FE8447@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 10:49:31 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX19oe7Ho/57mM49buhsjTTkmjaxzMNXBfgPMSYs Qw8ggswYk5pQ25Sd29bxtrYMsYRJFf5WxkcPYl5clk05hDwODg kPOU4v5T4dySFrWRuptug== Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:49:45 -0000 On Nov 16, 2009, at 9:12 AM, Eric Rescorla wrote: > At Mon, 16 Nov 2009 17:53:01 +0100 (MET), > Martin Rex wrote: >> >> And this is why it is very important that we can signal on ALL >> future TLS connections established by a client, so that a MITM >> can not FORCE an updated, but backwards compatible client to >> renegotiate insecurely with an updated, but backwards compatible >> server. >> This is what the TLS extensions RI currently fails completely. > > I don't agree with this claim. > > A client which sends RI only on renegotiation and aborts the > connection if it does not receive RI in return does not > have this problem. If *both* the client and the server are updated but backwards compatible, then they need a signal that the client can send in its initial handshakes. If the server ever sees this signal in a renegotiation handshake, this indicates a MitM attack -- which, without the signal, could be successful. The signal, thus, indicates to the server that treating the current handshake as a backwards- compatible renegotiation handshake is not acceptable. If we don't intend to allow updated servers to perform backwards- compatible renegotiation handshakes at all, we don't need this signal. I think this would make sense because we want to push forward to a point where there are only servers around that either (a) have been updated, or (b) don't use renegotiation in the first place. However, adding the signal seems easy enough: We can use a pseudo- ciphersuite value that would be listed by updated clients in all initial handshakes. (The specification should point out that this pseudo-ciphersuite must be listed also in handshakes that intend to resume a session, where some clients might be using an abbreviated ciphersuite list given that they already know one common ciphersuite.) Bodo From djhopwood@googlemail.com Mon Nov 16 10:56:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E8728C1FA for ; Mon, 16 Nov 2009 10:56:08 -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 wikbloCM25tv for ; Mon, 16 Nov 2009 10:56:07 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 525523A69E7 for ; Mon, 16 Nov 2009 10:56:07 -0800 (PST) Received: by qyk41 with SMTP id 41so2667679qyk.29 for ; Mon, 16 Nov 2009 10:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Q4Ys1L9KvM46TvKazIaqSVj1w9XeN7dyi4gPY+1mkc4=; b=EvQKHeecOfQTY+oHpoYeZCJbAvGut2743pZ3BM8LY3s6avAGY151n4rzacUq5hMJVp AvUmuL5VLHVIUond/wefqnGDHH84mhFyTL62Xduw3L989KefHawbWGkVbukZSNHK+KXZ tPvR6HuXtMHItDPzDw0KYhi61qgLMyMYirOoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=FT+DqpokV0oRPiTxpDOiwIJZ3ImHZQ95OtjHkT/K+jJImT250pJAiMP6YKH/FESEdU IiCWa7VrQeg/Ecoj0gvw1DUtO3Ml4ajNWYHXDQwKin38iEg7R8RmvWrHcoNJNZun39yw Sd/v0pHzWASHE9VZjKyVnlLRAaN9jeIIi0PHU= Received: by 10.213.0.138 with SMTP id 10mr2012345ebb.56.1258397763192; Mon, 16 Nov 2009 10:56:03 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 7sm1779165eyb.0.2009.11.16.10.56.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 10:56:02 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B01A041.80901@jacaranda.org> Date: Mon, 16 Nov 2009 18:56:01 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> In-Reply-To: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig0B1D68733F065FB9294CBC56" Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:56:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B1D68733F065FB9294CBC56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Eric Rescorla wrote: >> March Ray wrote: >> >>> What worries me are deployments like [all the parking meters and traf= fic >>> lights in ]. >>> >>> Or look at all the little plastic boxes returned from searches like t= his: >>> http://search.hp.com/query.html?qt=3Dssl/tls >> And what fraction of those devices will patch at all? >=20 > And this is why it is very important that we can signal on ALL > future TLS connections established by a client, so that a MITM > can not FORCE an updated, but backwards compatible client to > renegotiate insecurely with an updated, but backwards compatible server= =2E > This is what the TLS extensions RI currently fails completely. To solve this problem, a patched RI client simply must not renegotiate on= a connection that is in fallback mode. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig0B1D68733F065FB9294CBC56 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksBoEgACgkQWUc8YzyzqAex8wD/aZRwiTwnAO9A+tpVDRvJxN8u fA7Jv6O4K4hjjHUlrr4A/1CKdUZZDbHqorphARS4ujALFP/kPni+QWFIiOlj1XPa =JrMg -----END PGP SIGNATURE----- --------------enig0B1D68733F065FB9294CBC56-- From noskov@microsoft.com Mon Nov 16 10:57:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F70428C198 for ; Mon, 16 Nov 2009 10:57:48 -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 T3XTEqF9flqR for ; Mon, 16 Nov 2009 10:57:47 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2E8443A694E for ; Mon, 16 Nov 2009 10:57:47 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 16 Nov 2009 10:58:06 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server id 14.0.639.20; Mon, 16 Nov 2009 10:57:33 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 16 Nov 2009 10:57:34 -0800 From: Nasko Oskov To: "mrex@sap.com" Thread-Topic: [TLS] Deployment data Thread-Index: AQHKZuzXliSd/5d6JkiShJC+Xn1Y+pE5Dd2Q Date: Mon, 16 Nov 2009 18:56:25 +0000 Deferred-Delivery: Mon, 16 Nov 2009 18:57:00 +0000 Message-ID: References: <4B0199DD.5080904@pobox.com> from "Michael D'Errico" at Nov 16, 9 10:28:45 am <200911161844.nAGIiZtw019142@fs4113.wdf.sap.corp> In-Reply-To: <200911161844.nAGIiZtw019142@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:57:48 -0000 >Michael D'Errico wrote: >>=20 >> You do not appear to fully understand the attack. It is completely=20 >> unnecessary for a client to abort a renegotiation. There is no=20 >> possible man-in-the-middle. This is guaranteed when the client has=20 >> verified the server's certificate in its initial handshake. >> Otherwise ALL of TLS would be broken. >>=20 >> Now, it is necessary for a client to use whatever-the-fix-is when=20 >> renegotiating so that the *server* can check for insecure=20 >> renegotiation, but this is purely mechanical to the client. > >I really would appreciate an extension-less negotiation through >ClientHello+ServerHello where the Server can confirm to the client >that it will do the modified finished calculation on renegotiations, so th= at the client knows that its initial handshake can not be proxied into the = reneogotiation of a server (will fail the finished mac if done).=20 I consider signaling on both directions vital. The TLS stack should not dic= tate application policy whether secure/insecure renegotiation is used. This= is application level logic, though default behavior will be present. The d= efault could go out with allowing insecure renegos to allow for interop at = the time of release, but can be tightened up once the fix has gained enough= traction. If we cannot provide signaling in both directions, then apps need to do fal= lback, which for non-browers apps is a pretty big breaking change. Nasko From bmoeller@acm.org Mon Nov 16 10:58:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BCB28C1FE for ; Mon, 16 Nov 2009 10:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.027 X-Spam-Level: X-Spam-Status: No, score=-102.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 XwZtRCS+ipiA for ; Mon, 16 Nov 2009 10:58:11 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id E558228C1FD for ; Mon, 16 Nov 2009 10:58:10 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MKMb4-1NBlTC2Deo-001rMY; Mon, 16 Nov 2009 19:58:09 +0100 From: Bodo Moeller To: Michael D'Errico In-Reply-To: <4B0199DD.5080904@pobox.com> References: <20091116055101.9D38969F87F@kilo.networkresonance.com> <20091116171246.772ED69F9E5@kilo.networkresonance.com> <4B0199DD.5080904@pobox.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 10:58:06 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+ejhpPd2eIbI1RSmbiHPsUaI0qoohCNMcnNdW GiKZUoN310uKcRh7LL2YlwOBaxmnIyb3ZjyLv/3nMigd/SanS3 9+pT9Knn/WoSThb87O18A== Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:58:11 -0000 On Nov 16, 2009, at 10:28 AM, Michael D'Errico wrote: >> A client which sends RI only on renegotiation and aborts the >> connection if it does not receive RI in return does not have this >> problem. > > You do not appear to fully understand the attack. It is completely > unnecessary for a client to abort a renegotiation. There is no > possible man-in-the-middle. This is guaranteed when the client has > verified the server's certificate in its initial handshake. It is NOT guaranteed, however, if the initial handshake was for an anonymous cipersuite, with a renegotiation handshake taking place once the client and server think they should introduce to each other. This is a perfectly valid TLS use case. Bodo From bmoeller@acm.org Mon Nov 16 11:01:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7AF3A684F for ; Mon, 16 Nov 2009 11:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Ydt3WwlMTOKN for ; Mon, 16 Nov 2009 11:01:47 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 123743A67B5 for ; Mon, 16 Nov 2009 11:01:47 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M36xf-1O2DWF1wKF-00sRll; Mon, 16 Nov 2009 20:01:42 +0100 From: Bodo Moeller To: David-Sarah Hopwood In-Reply-To: <4B01A041.80901@jacaranda.org> References: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> <4B01A041.80901@jacaranda.org> Message-Id: <1264410A-9D46-4395-8BF9-092CCFC7196F@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 11:01:38 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX19r35iKC8sBX36C2ZZKtMjGMjumIJqmPlMqfS4 aSMwfV8scq4UWG5WC14mfcfzOXnIyar2z1W7GqJXMTLBu9lhHI bpGmkQPo3NbadG860J8Sw== Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:01:48 -0000 On Nov 16, 2009, at 10:56 AM, David-Sarah Hopwood wrote: > Martin Rex wrote: >> And this is why it is very important that we can signal on ALL >> future TLS connections established by a client, so that a MITM >> can not FORCE an updated, but backwards compatible client to >> renegotiate insecurely with an updated, but backwards compatible >> server. >> This is what the TLS extensions RI currently fails completely. > > To solve this problem, a patched RI client simply must not > renegotiate on a > connection that is in fallback mode. This solves the problem only if we don't allow updated servers to perform backwards-compatible renegotiation handshakes. If we do allow this, we have to worry about a MitM attacker relaying the client's initial handshake to the server as a fallback-mode renegotiation handshake. Bodo From marsh@extendedsubset.com Mon Nov 16 11:06:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B5B3A69E5 for ; Mon, 16 Nov 2009 11:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, 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 JfycCuk7t7Hg for ; Mon, 16 Nov 2009 11:06:58 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 58E603A694E for ; Mon, 16 Nov 2009 11:06:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NA6ue-000P0n-NN for tls@ietf.org; Mon, 16 Nov 2009 19:06:56 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D7872667C for ; Mon, 16 Nov 2009 19:06:55 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX199RyoGTyJmqRGeOggqcHdViGAyTLAc+qA= Message-ID: <4B01A2CB.4060404@extendedsubset.com> Date: Mon, 16 Nov 2009 13:06:51 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls >> \"tls@ietf.org\"" References: <200911161029.nAGAT8uN019401@fs4113.wdf.sap.corp> <4B01923F.9020806@pobox.com> <4B019434.9020001@extendedsubset.com> <4B019BC7.2080201@pobox.com> In-Reply-To: <4B019BC7.2080201@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:06:59 -0000 Michael D'Errico wrote: > If a client doesn't check the server's certificate, it is subject to > any man-in-the-middle attack. I was going to give the example of an anonymous server and an authenticated client, but it seems prohibited by the spec: "Anonymous servers cannot authenticate clients". Nevertheless, it could be done with anonymous connections in which the client retro-actively authenticates the server. One sees this kind of thing in sample code all the time. > One of the requirements is that a client > verify the certificate. Read closely: > If the server is authenticated, > its certificate message must provide a valid certificate chain > leading to an acceptable certificate authority. Similarly, > authenticated clients must supply an acceptable certificate to the > server. Each party is responsible for verifying that the other's > certificate is valid and has not expired or been revoked. It requires that the endpoints _validate_ the cert chain. I haven't found where the spec says the certs have to be the right ones. Indeed it seems that a common application error is to hand the TLS library an open socket and let it validate whatever cert shows up from the server. Another form of "authentication gap" perhaps? > If a client doesn't do that, how can we > possibly protect it??? By restoring the application-API guarantee that was lost when renegotition was added to ssl: both ends know they are talking to the same part during the entire connection, even if some of the sessions have one or more anonymous endpoints. > I'm interested in providing the best defense to a client that is aware > of the MITM renegotiation problem when faced with having to interact > with possibly-unpatched servers. Definitely. Also the best defense to patched servers talking to unpatched clients, with or without renegotiation. - Marsh From mrex@sap.com Mon Nov 16 11:12:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E49228C1FC for ; Mon, 16 Nov 2009 11:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.347, 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 I8GOrTVoAC1q for ; Mon, 16 Nov 2009 11:12:27 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 4028228C1F2 for ; Mon, 16 Nov 2009 11:12:26 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAGJCN8B024331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 20:12:23 +0100 (MET) From: Martin Rex Message-Id: <200911161912.nAGJCMU2020921@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 16 Nov 2009 20:12:22 +0100 (MET) In-Reply-To: <20091116112846.82CF269F8D7@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 01:28:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:12:29 -0000 Eric Rescorla wrote: > > This is an interesting suggestion, but I think it has some problematic > aspects. The other options you're looking for are described in <200911161053.nAGAr1DS020959@fs4113.wdf.sap.corp> Date: Mon, 16 Nov 2009 11:53:00 +0100 > > We could use other mechanisms, such as ServerRandom signalling, but > we're now at the point where we're generating a lame version of > extension signalling using other mechanisms. Absent some evidence that > there is a real SSLv3 compatibility issue, I'm not sure why that's a > good idea. I really don't see this fix as an extension. It should have been an integral part of the SSLv3 protocol from the beginning. This situation is really special. So far it is a one in 14 years event. I do not expect that it is going to reoccur on a regular basis that we have to go back several protocol revisions to fix such a comparably significant shortcoming the TLS base protocol. > > On an aesthetic level, the TLS handshake hashes are just that, > handshake hashes. Injecting new data into that computation doesn't > strike me as really that architecturally fantastic an idea. If we > were to go down that road, I suspect that Rob Dugal's suggestion > of just continuing the handshake hashes would be superior. I only mind the TLS extension wrapping and sending the finished messages unnecessarily over the wire. Otherwise I'm very open. Continuing the handshake messages creates one little theoretical problem. In theory a client could send out a new ClientHello right after the client.finished message and not wait for Server.finished. (SSLv3 explicitly says this, but I think this text was removed in TLS). In discussions about cutting down the number of round-trips I had also suggested such an optimization (which is similar to piggy-back data on the last security context token of a gssapi security context establishment with an odd number of context-level tokens for security context establishment). For that scenario, continuing the handshake message hash would not work, I believe. During the past, people who asked for client identity protection in TLS client cert authentication were given the advise to immediately renegotiate. There, where such an optimization springs to mind, simply continuing with the handshake message hash before ClientHello would interfere with starting renegotiating without waiting for the server.finished. This is why I suggested adding the verify_data of the previous finished messages always directly after ServerHello. -Martin From noskov@microsoft.com Mon Nov 16 11:16:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD9728C20C for ; Mon, 16 Nov 2009 11:16:08 -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 ve0SOM2i4J+R for ; Mon, 16 Nov 2009 11:16:06 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D3D1428C200 for ; Mon, 16 Nov 2009 11:16:06 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 16 Nov 2009 11:16:06 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server id 14.0.639.20; Mon, 16 Nov 2009 11:16:00 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 16 Nov 2009 11:16:01 -0800 From: Nasko Oskov To: David-Sarah Hopwood , "tls@ietf.org" Thread-Topic: [TLS] Protecting against a MITM Thread-Index: AQHKZku/6S067tV2EUeGRuSen/D5i5E4daaAgAAwW4CAAEvNgIAAICMQ Date: Mon, 16 Nov 2009 19:14:50 +0000 Deferred-Delivery: Mon, 16 Nov 2009 19:15:00 +0000 Message-ID: References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> <4B00D699.7030902@pobox.com> <4B01162F.9050708@jacaranda.org> In-Reply-To: <4B01162F.9050708@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CkfX C9pK FdoC HP2f IGc/ JsQb J3Ww KS/3 Kkk8 QfNg QfgQ Q30D RHYp R1oN R5r1 WCsY; 2; ZABhAHYAaQBkAC0AcwBhAHIAYQBoAEAAagBhAGMAYQByAGEAbgBkAGEALgBvAHIAZwA7AHQAbABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {26CBF392-4860-4200-A43B-013EBF243EE2}; bgBvAHMAawBvAHYAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Mon, 16 Nov 2009 19:15:00 GMT; UgBFADoAIABbAFQATABTAF0AIABQAHIAbwB0AGUAYwB0AGkAbgBnACAAYQBnAGEAaQBuAHMAdAAgAGEAIABNAEkAVABNAA== x-cr-puzzleid: {26CBF392-4860-4200-A43B-013EBF243EE2} Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Protecting against a MITM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:16:08 -0000 RGF2aWQtU2FyYWggSG9wd29vZCB3cm90ZToNCj5NaWNoYWVsIEQnRXJyaWNvIHdyb3RlOg0KPj4+ PiBSSSB3aXRoIHBhdGNoZWQgY2xpZW50IC8gdW5wYXRjaGVkIHNlcnZlcjoNCj4+Pj4NCj4+Pj4g ICAgUGVvcGxlIGNvbnRpbnVlIHRvIHN1Z2dlc3QgdGhhdCB3aXRoIHRoZSBSSSBleHRlbnNpb24s IGEgY2xpZW50DQo+Pj4+ICAgIGRvZXNuJ3QgbmVlZCB0byBzZW5kIGl0IG9uIGl0cyBpbml0aWFs IGhhbmRzaGFrZS4gIFRoaXMgaXMgY29tcGxldGVseSB3cm9uZy4NCj4+Pg0KPj4+IEl0IGlzIG5v dCAiY29tcGxldGVseSB3cm9uZyIuIEZvciBhIHBhdGNoZWQgY2xpZW50LCBub3Qgc2VuZGluZyBh IA0KPj4+IHNpZ25hbCBvbiB0aGUgaW5pdGlhbCBoYW5kc2hha2UgKHJlZ2FyZGxlc3Mgb2YgdGhl IGZvcm0gb2YgdGhhdCANCj4+PiBzaWduYWwpIG1hdHRlcnMgaWYtYW5kLW9ubHktaWYgdGhlIGNs aWVudCBpcyBnb2luZyB0byByZWZ1c2UgdG8gDQo+Pj4gaW50ZXJvcGVyYXRlIHdpdGggdW5wYXRj aGVkIHNlcnZlcnMuDQo+PiANCj4+ICJJbnRlcm9wZXJhdGluZyB3aXRoIHVucGF0Y2hlZCBzZXJ2 ZXJzIiBtZWFucyBleHBvc2luZyB5b3Vyc2VsZiB0byBhbiANCj4+IGF0dGFjay4NCj4+IFdlIGNh bid0IHByb3RlY3QgYWdhaW5zdCB0aGF0IGJlaGF2aW9yLiAgSXQgbWF5IGluaXRpYWxseSBiZSBu ZWNlc3NhcnkgDQo+PiB0byBkbyB0aGlzIHVudGlsIHdpZGVzcHJlYWQgYWRvcHRpb24gb2YgdGhl IGZpeCBoYXBwZW5zLCBidXQgaXQgaXMgDQo+PiBjZXJ0YWlubHkgbm90IHNhZmUgbG9uZyB0ZXJt Lg0KPg0KPkkgZGlkbid0IHNheSB0aGF0IGl0IHdhcy4NCj4NCj5UaGUgc29sdXRpb24gbXVzdCBz dXBwb3J0IGF0IGxlYXN0IGJvdGggc3RyaWN0IGFuZCBsZW5pZW50IGNsaWVudCBwb2xpY2llcywN Cj5pLmUuIGVpdGhlciByZWZ1c2luZyBvciBhbGxvd2luZyBjb25uZWN0aW9ucyB0byB1bnBhdGNo ZWQgc2VydmVycy4gSSBkb24ndA0KPnRoaW5rIHRoZXJlIGlzIGFueSBkaXNwdXRlIGFib3V0IHRo YXQsIGlzIHRoZXJlPw0KDQpJIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGFsbG93IGJvdGggc3RyaWN0 IGFuZCBsZW5pZW50IGNsaWVudCBwb2xpY2llcy4gVGhpcw0KY2FuIG9ubHkgYmUgZG9uZSBpZiB0 aGUgc2VydmVyIHNpZ25hbHMgaXRzIHBhdGNoZWQgc3RhdGUgdG8gdGhlIGNsaWVudC4NCg0KPj4+ IFRoZXNlIGtpbmRzIG9mICJtaXNjaGllZiBieSBhIE1JVE0iIHdvbid0IHdvcmsuIFsuLi5dDQo+ PiANCj4+IEluIG1vc3QgY2FzZXMgSSB0aGluayB5b3UgYXJlIHJpZ2h0LCBidXQgaW1hZ2luZSB0 aGVyZSBpcyBhIHNlcnZlciBvdXQgDQo+PiB0aGVyZSB0aGF0IHJlcXVpcmVzIHJlbmVnb3RpYXRp b24gdG8gb2J0YWluIGNsaWVudCBjcmVkZW50aWFscy4NCj4NCj5PSy4uLg0KPg0KPj4gSW4gb3Jk ZXIgdG8gY29udGludWUgcHJvdmlkaW5nIHNlcnZpY2UgdG8gY2xpZW50cywgaXQgbWF5IGJlIA0K Pj4gY29uZmlndXJlZCB0byBzdGlsbCBwZXJmb3JtIGluc2VjdXJlIHJlbmVnb3RpYXRpb25zIGR1 cmluZyBhIHRyYW5zaXRpb24gcGVyaW9kLg0KPg0KPlRoZW4gaXQgaXMgbm90IGZpeGVkLCBhbmQg aXMgbm9uY29uZm9ybWFudCB0byB0aGUgUkkgZHJhZnQuDQo+DQo+PiBBIE1JVE0gY2FuIGVhc2ls eSBtYWtlIHRoaXMgc2VydmVyIGFwcGVhciB0byBicmVhayB1cG9uIHJlY2VpdmluZyB0aGUgDQo+ PiBSSSBleHRlbnNpb24uIElmIHRoZSBjbGllbnQgaGFzIGEgZmFsbGJhY2sgdG8gbm90IHVzZSB0 aGUgUkkgDQo+PiBleHRlbnNpb24sIHRoZW4gdGhlIE1JVE0gaXMgYWJsZSB0byBjYXVzZSB0aGUg Y2xpZW50IGFuZCBzZXJ2ZXIsIGJvdGggDQo+PiBvZiB3aGljaCBhcmUgcGF0Y2hlZCwgdG8gcmV2 ZXJ0IGJhY2sgdG8gaW5zZWN1cmUgYmVoYXZpb3IuDQo+DQo+VGhhdCdzIG5vdCBjbGVhci4gSSB0 aGluayBpdCBkZXBlbmRzIG9uIHByZWNpc2VseSBob3cgdGhlIGZhbGxiYWNrDQo+bWVjaGFuaXNt IGlzIGltcGxlbWVudGVkLiBJZiB0aGUgcGF0Y2hlZCBjbGllbnQgcmVmdXNlcyB0byByZW5lZ290 aWF0ZSB3aGVuDQo+aXQgaXMgaW4gZmFsbGJhY2sgbW9kZSwgdGhlbiBJIGNhbm5vdCBpbW1lZGlh dGVseSBzZWUgYW55IGF0dGFjay4NCj4NCj5JIGFncmVlIHRoYXQgYm90aCB5b3VyIHByb3Bvc2Fs IGFuZCBtaW5lIGFyZSBwb3RlbnRpYWxseSBtb3JlIHJvYnVzdCB0aGFuDQo+UkkgaGVyZSwgc2lu Y2UgdGhleSBib3RoIGNoYW5nZSB0aGUgRmluaXNoZWQgaGFzaCBjb21wdXRhdGlvbiBmb3INCj5y ZW5lZ290aWF0aW9ucyBldmVuIHdoZW4gZXh0ZW5zaW9ucyBhcmUgKm5vdCogc2VudC4NCg0KT25l IGJlbmVmaXQgb2Ygc2VuZGluZyBpbmZvcm1hdGlvbiBvbiB0aGUgd2lyZSBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZQ0Kc2VydmVyIGlzIHRoYXQgaWYgYm90aCBlbmRzIGFyZSBwYXRjaGVkIGFu ZCBjb25maWd1cmVkIGFzIGxlbmllbnQsIHRoZXkgYXJlDQpzdGlsbCBzZWN1cmUuIE1pVE0gbW9j a2luZyB3aXRoIGFueSBvZiB0aGUgdHJhZmZpYyBpcyBib3VuZCB0byBicmVhayB0aGUNCmZpbmlz aGVkIG1lc3NhZ2UgY29tcGFyaXNvbiwgc28gYXMgbG9uZyBhcyBjbGllbnQgYW5kIHNlcnZlciBz aWduYWwgZWFjaA0Kb3RoZXIsIHRoZXkgYXJlIHNhZmUuIFRoaXMgSU1ITyBpcyBhIGJpZyBwbHVz IG9mIHNpZ25hbGluZyBiZXR3ZWVuIHRoZSB0d28NCnNpZGVzLiBJdCBjYW4gYmUgYWNoaWV2ZWQg dXNpbmcgYW4gZXh0ZW5zaW9uIG9yIHdpdGggbW9ja2luZyB3aXRoIHRoZQ0KKkhlbGxvIG1lc3Nh Z2VzLiBJIGJlbGlldmUgdGhlIGV4dGVuc2lvbiBhcHByb2FjaCB3aWxsIGhhdmUgbW9yZSBkZWZp bmVkDQppbnRlcm9wIHN0b3J5IHRoYW4gY2hhbmdpbmcgYW55dGhpbmcgaW4gdGhlIG1lc3NhZ2Vz Lg0KDQo+PiBXaXRoIG15IHByb3Bvc2FsLCBpdCBpcyBhbHNvIHBvc3NpYmxlIGZvciBhIE1JVE0g dG8gYWx0ZXIgdGhlIA0KPj4gaGFuZHNoYWtlLCBidXQgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCB0 aGUgc2VydmVyIGNhbiBwcm92ZSBpdCBoYXBwZW5lZCANCj4+IHNpbmNlIG5laXRoZXIgRmluaXNo ZWQgY29tcHV0YXRpb24gd2lsbCBtYXRjaC4NCj4NCj5JZiB0aGUgc2VydmVyIGlzIGNvbmZpZ3Vy ZWQgdG8gcGVyZm9ybSBpbnNlY3VyZSByZW5lZ290aWF0aW9ucywgdGhlbiBpbg0KPnlvdXIgcHJv cG9zYWwgaXQgbXVzdCBhY2NlcHQgYSBjbGllbnQgRmluaXNoZWQgbWVzc2FnZSB3aXRoIHRoZSB1 bmNoYW5nZWQNCj5oYXNoIGNvbXB1dGF0aW9uLiBTbyBhbiBhdHRhY2sgaXMgY2VydGFpbmx5IHBv c3NpYmxlIHdoZW4gdGhlIGNsaWVudCBpcw0KPnVucGF0Y2hlZC4gSSdsbCBoYXZlIHRvIHRoaW5r IHNvbWUgbW9yZSBhYm91dCB0aGUgc2VjdXJpdHkgb2YgUkkgaW4gdGhlDQo+ZmFsbGJhY2sgY2Fz ZSB3aGVuIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgYXJlIHBhdGNoZWQgKGJ1dCBsZW5pZW50KTsg aXQncw0KPm5vdCBhdCBhbGwgb2J2aW91cy4NCg0KSXQgc2hvdWxkIGJlIHNlY3VyZS4gTWlUTSBz aG91bGQgbm90IGJlIGFibGUgdG8gYWx0ZXIgdGhlIG1lc3NhZ2VzIGluIHRoZQ0KVExTIGhhbmRz aGFrZSB3aXRob3V0IGRldGVjdGlvbiAob3RoZXJ3aXNlIHdlIGhhdmUgYmlnZ2VyIHByb2JsZW0p LiBBcyBsb25nDQphcyBjbGllbnQgYW5kIHNlcnZlciBib3RoIHNlbmQgdGhlIGluZm8gdG8gdGhl IG90aGVyIHBhcnR5LCB3ZSBhcmUgc2VjdXJlDQpldmVuIGluIGxlbmllbnQgbW9kZS4gQW0gSSBt aXNzaW5nIHNvbWV0aGluZz8NCg0KPj4+PiBUaGlzIHNvbHV0aW9uIGlzIHRvIG1ha2UgYXZhaWxh YmxlIGEgbW9kaWZpZWQgRmluaXNoZWQgY2FsY3VsYXRpb24gDQo+Pj4+IHRoYXQgYSBwYXRjaGVk IGNsaWVudCBjYW4gdXNlIGZvciBhbGwgaGFuZHNoYWtlcyBpbmNsdWRpbmcgdGhlIA0KPj4+PiBp bml0aWFsIG9uZS4gIFRoaXMgc29sdXRpb24gZG9lcyBub3QgZXZlbiBicmVhayBjb21wYXRpYmls aXR5IHdpdGggDQo+Pj4+IG9sZCBjbGllbnRzIC0tIGEgc2VydmVyIHdvdWxkIHN1cHBvcnQgQk9U SCB0aGUgb2xkIGFuZCB0aGUgbmV3IA0KPj4+PiBGaW5pc2hlZCBtZXNzYWdlIGNvbXB1dGF0aW9u IGFuZCBkbyB0aGUgcmlnaHQgdGhpbmcgYmFzZWQgb24gd2hpY2ggDQo+Pj4+IG9uZSB3YXMgdXNl ZCBieSB0aGUgY2xpZW50Lg0KDQpJIGJlbGlldmUgdGhpcyByZXF1aXJlcyBrZWVwaW5nIGEgbW9y ZSBzdGF0ZSBkYXRhIHRoYW4gdGhlIGZpbmlzaGVkIG1lc3NhZ2VzDQotPiBtb3JlIG1lbW9yeSBp bnRlbnNpdmUgb24gdGhlIHNlcnZlciBzaWRlLg0KDQo+Pj4gVGhpcyBoYXMgYSBzaWduaWZpY2Fu dCBkaXNhZHZhbnRhZ2UgcmVsYXRpdmUgdG8gdGhlIFJJIHByb3Bvc2FsOg0KPj4+IENvbnNpZGVy IGEgcGF0Y2hlZCBjbGllbnQgdGhhdCB3YW50cyB0byBjb25uZWN0IHRvIHVucGF0Y2hlZCBzZXJ2 ZXJzLg0KPj4+IFdpdGggeW91ciBzdWdnZXN0ZWQgYXBwcm9hY2gsIHN1Y2ggYSBjbGllbnQgbXVz dCB1c2UgdGhlIG9sZCBGaW5pc2hlZCANCj4+PiBtZXNzYWdlIGNvbXB1dGF0aW9uIG9uIGFuIGlu aXRpYWwgaGFuZHNoYWtlIChvciBlbHNlIGl0IG11c3QgYWRkIGEgDQo+Pj4gZmFsbGJhY2sgaW4g b3JkZXIgdG8gY29ubmVjdCB0byB0aG9zZSBzZXJ2ZXJzLCB3aGljaCBpcyB1bmRlc2lyYWJsZSku DQo+Pj4gVGhlcmVmb3JlLCBpdCBpc24ndCBkaXN0aW5ndWlzaGFibGUgZnJvbSBhbiB1bnBhdGNo ZWQgY2xpZW50IGJ5IA0KPj4+IGxvb2tpbmcgYXQgY2xlYXJ0ZXh0IGhhbmRzaGFrZSBtZXNzYWdl cy4NCj4+IA0KPj4gSSdtIHN1Z2dlc3RpbmcgdG8gZ2l2ZSB1cCBjbGVhcnRleHQgcGF0Y2ggc3Rh dHVzIGZvciBiZXR0ZXIgYXR0YWNrIA0KPj4gZGV0ZWN0aW9uIGFuZCBiZXR0ZXIgaW50ZXJvcGVy YWJpbGl0eSBzaW5jZSB0aGVyZSBpcyBOTyBjaGFuZ2UgdG8gYml0cyANCj4+IG9uIHRoZSB3aXJl LCBubyBuZWVkIGZvciBleHRlbnNpb25zIG9yIGV2ZW4gVExTIChTU0x2MyBjYW4gYmUgZml4ZWQg aW4gDQo+PiBleGFjdGx5IHRoZSBzYW1lIHdheSkuDQo+DQo+TXkgcHJvcG9zYWwgYWxzbyBmaXhl cyB0aGUgRmluaXNoZWQgaGFzaCBjb21wdXRhdGlvbiBmb3IgU1NMdjMgaW4gZXhhY3RseSB0aGUg c2FtZSB3YXkgYXMgZm9yIFRMUy4NCg0KTm93LCBjYW4geW91IGFkZCAqcmVsaWFibGUqIHNpZ25h bGluZyBpbiBib3RoIGRpcmVjdGlvbnM/DQoNCk5hc2tvDQo= From bmoeller@acm.org Mon Nov 16 11:17:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33AC93A6977 for ; Mon, 16 Nov 2009 11:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 UJ2Dirqjw3Bq for ; Mon, 16 Nov 2009 11:17:37 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 2DD9B3A67B5 for ; Mon, 16 Nov 2009 11:17:37 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MbcQr-1NSbIV2Lzx-00Iqbz; Mon, 16 Nov 2009 20:17:16 +0100 From: Bodo Moeller To: mrex@sap.com In-Reply-To: <200911161844.nAGIiZtw019142@fs4113.wdf.sap.corp> References: <200911161844.nAGIiZtw019142@fs4113.wdf.sap.corp> Message-Id: <40F7948A-CC15-436C-9237-66F0ABED8A38@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 11:17:12 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+1hBvl1+8VU4Gy8TgZE/p7XfxwqJjMyVAvHf/ gsq404OziUXSZriPC5Uri+j1OBqKjYtxsPU4P1RH/RlPi7B2jG mmAvBaIv+BH2O4eo4wA9w== Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:17:38 -0000 On Nov 16, 2009, at 10:44 AM, Martin Rex wrote: > I really would appreciate an extension-less negotiation through > ClientHello+ServerHello where the Server can confirm to the client > that it will do the modified finished calculation on renegotiations, > so that the client knows that its initial handshake can not be proxied > into the reneogotiation of a server (will fail the finished mac if > done). I don't see why we'd want this to be extension-less for this purpose. If the client wants the initial handshake to fail if the server doesn't confirm that it is using updated renegotiation logic, this means that we want to achieve interoperability only if both the client and the server have been updated. Why not specify that this update will have to include minimal extension support (where the client uses a single fixed extension and checks whether the server confirms it, and the server looks for this single fixed extension in the client_hello_extension_list and sends the fixed extension back if appropriate), even for SSL 3.0? If client do such handshakes with servers that haven't been updated and choke on extensions, these handshakes will fail -- which is just as expected if the client only wants to talk to those servers for which it has positive confirmation that they've been updated. Bodo From djhopwood@googlemail.com Mon Nov 16 11:31:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBAEE28C20E for ; Mon, 16 Nov 2009 11:31:11 -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 VdLChUOOLHn7 for ; Mon, 16 Nov 2009 11:31:10 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 72E6228C20C for ; Mon, 16 Nov 2009 11:31:10 -0800 (PST) Received: by fxm7 with SMTP id 7so6131953fxm.29 for ; Mon, 16 Nov 2009 11:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=L/QasDaQfKxIGbTuoSucv7SY/0CxuNhb93TTxLLQ6tI=; b=bI2BrSOGbxWPS6lUL5exhYUiBxOP+YqLQmCeEmZwJkse9Tn+5sueHr/4wu0+4wbZGU UWum8iyzUiLaBf48wEDnaLkWmSZuI0Ki8V04jjA5y9x6CCeEtKUMYDL/2e9lIJIyQv9z PG2wPdHlraVX6DTkRvYjbicaYNrio/FTqThWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=PpqPjCSdRB1kOTERw49vOY2Y9zVrtDKT5yPNyJiErolLSXKEhG4sAIK3dEBjppfXL2 0TxVO2cpGN9S6o/BxY0gQjj7qMuDhYL+1mrDuvRyq5xqK3djvCwqsRa8jGEBdnYPuEYz E7bKNTnitrt/JsxKMf7K4Kr+wAODxJAeIT9Aw= Received: by 10.102.160.15 with SMTP id i15mr3838047mue.130.1258399865376; Mon, 16 Nov 2009 11:31:05 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id j6sm731869mue.20.2009.11.16.11.31.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 11:31:04 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B01A872.1010509@jacaranda.org> Date: Mon, 16 Nov 2009 19:30:58 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp> In-Reply-To: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig754197D11C42EE032397F51E" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:31:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig754197D11C42EE032397F51E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Do you realize how much implementation and testing is involved when > shipping the fix as a TLS extension. Yes. Are you suggesting that a fix that uses some other ad hoc signalling= mechanism does not need to undergo thorough interoperability testing? > If someone with an old server, who doesn't implement renegotiation and > TLS extensions wants to add this patch, he will need to add the entire > TLS extensions handling in a generic fashion and require a significantl= y > larger interop testing scenario to make sure that it acutally works: If a server doesn't implement renegotiation, then it is already as secure= as it can be with respect to this attack. The server only needs to be patched so that strict clients will recognize it as patched. To achieve that, the server clearly must signal something in a message that it sends. If that is not done using an extension, then it must be done using another mechanism such as recognizing a magic ciphersuite and stuffing its response in some covert channel (which I cannot believe we are even seriously discussing, frankly). Remember, complicated kludges such as fallback to accomodate broken serve= r implementations are only needed, if they are needed at all, on the client= side. Implementing extensions on the server side is completely trivial. Many server implementors have already done that work, whereas *no* server= implementors have done the work to support any newly invented signalling mechanism. > You're going to waste network bandwith eternally in a completely > useless fashion. The bandwidth usage is completely insignificant, even for highly constrai= ned environments. If I've calculated correctly, the size of the extension is 5 bytes in each direction in the most common, non-renegotiating case (17 or 29 bytes when renegotiating), and it adds no round-trips. Compare that to X.509 certificate sizes, which are typically at least 1 KiB each.= --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig754197D11C42EE032397F51E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksBqH4ACgkQWUc8YzyzqAelrAD/ep90sPQtGSbMJdeQ4te2yN+p moU2yvj2cYyApLRlq0kA/AxOHOo41xZF+P6Ttbesfk+VBNig2Sjzrdg0oEJUfqgW =GzOt -----END PGP SIGNATURE----- --------------enig754197D11C42EE032397F51E-- From mrex@sap.com Mon Nov 16 11:44:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3350D3A69FE for ; Mon, 16 Nov 2009 11:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[AWL=0.330, 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 OmCnb2I81yse for ; Mon, 16 Nov 2009 11:44:14 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id EEC8E3A6993 for ; Mon, 16 Nov 2009 11:44:13 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAGJi9hX007939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 20:44:09 +0100 (MET) From: Martin Rex Message-Id: <200911161944.nAGJi88Q022752@fs4113.wdf.sap.corp> To: bmoeller@acm.org (Bodo Moeller) Date: Mon, 16 Nov 2009 20:44:08 +0100 (MET) In-Reply-To: <40F7948A-CC15-436C-9237-66F0ABED8A38@acm.org> from "Bodo Moeller" at Nov 16, 9 11:17:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:44:15 -0000 Bodo Moeller wrote: > > On Nov 16, 2009, at 10:44 AM, Martin Rex wrote: > > > I really would appreciate an extension-less negotiation through > > ClientHello+ServerHello where the Server can confirm to the client > > that it will do the modified finished calculation on renegotiations, > > so that the client knows that its initial handshake can not be proxied > > into the reneogotiation of a server (will fail the finished mac if > > done). > > I don't see why we'd want this to be extension-less for this purpose. So that the client can signal it on EVERY SSLv3 or TLS handshake that it can be configured to do. Currently, Browsers have either automatic fallbacks to extension-less ClientHellos or can be configured for SSLv3 (which is the default for MSIE) in a comparable fashion where they send only extension-less ClientHellos, simply because TLS extensions are known to upset servers. > > If the client wants the initial handshake to fail if the server > doesn't confirm that it is using updated renegotiation logic, this > means that we want to achieve interoperability only if both the client > and the server have been updated. An SSLv3 or TLSv1.0 Server that has neither TLS extensions nor renegotition implemented must add an awful lot of code in order to do signaling through TLS extensions. And interop testing that code isn't exactly easy (because the client may send the extension anywhere among other extensions). Servers will usually already have code to parse and search the list of ciphersuite IDs sent in the ClientHello, so is likely significantly less new code and less testing necessary. > > Why not specify that this update will have to include minimal > extension support (where the client uses a single fixed extension and > checks whether the server confirms it, and the server looks for this > single fixed extension in the client_hello_extension_list and sends > the fixed extension back if appropriate), even for SSL 3.0? I really do _not_ think it is a good idea to make TLS extensions retroactively mandatory to implement (especially right now), since TLS extensions have been a purely optional feature for the installed base of TLSv1.1 and didn't even exist when TLSv1.0 was finalized, and the TLS WG has been well aware about significant interop problems with TLS extensions for at least 3 years (draft-pettersen-tls-interop-experience-00.txt) and didn't do all that much to change this in the meantime. > > If client do such handshakes with servers that haven't been updated > and choke on extensions, these handshakes will fail -- which is just > as expected if the client only wants to talk to those servers for > which it has positive confirmation that they've been updated. The IETF has permitted a 13-year growth of an installed base that implements the existing protocols SSLv3->TLSv1.2 with that shortcoming. It is no longer at the discretion to TLS alone to discontinue the interoperability with the installed base from one day to the next. This is a decision that we must leave at the discretion of the consumers of the TLS technology. I think we should really try hard to make the transistion from the installed base to patched as simple and smooth as possible, allow them to decide individually when to break interop, provide the highest possible security for all existing usage scenarios. SSLv3 may have not originated in the IETF (the spec document, however, was under discussion in the IETF). But TLS set out to be clearly interoperable with SSLv3, so we can not simply pull the plug and leave them in misery -- in particular since we are able to devise a patch that is simpler than a TLS extension and will fit equally well across all protocol versions of TLS including SSLv3. -Martin From djhopwood@googlemail.com Mon Nov 16 11:47:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9A03A67F7 for ; Mon, 16 Nov 2009 11:47: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=[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 ZLezBtotQII0 for ; Mon, 16 Nov 2009 11:47:37 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id D27E23A67B5 for ; Mon, 16 Nov 2009 11:47:36 -0800 (PST) Received: by bwz23 with SMTP id 23so6145825bwz.29 for ; Mon, 16 Nov 2009 11:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=qWUrGt8MGeJzvCrDK6Skl6uH0qiXss03UDPkZZzaEV4=; b=p+8+6RlXqd6puvOKhQF/m35OKKMHM0xfP4hTaYMkGpVukAb+j23Im4/6ENRij/Dt/e PH2FRvxp8IzJCgrEhWBcjS7gQ1gte2r1m02+Ic4BhTtICOCCGcjTkCVTTDgAHb5KluCN jXVAvJjpq3kzL+7WCazVhjXzMP1wZF7hSuIj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=WNMsOD/brB5TOYChU14TFE/kX0nl/X3KM/NOguo6xJVJ3cuF4lf1GWVp6cOrWvwc3X +pS/IM9BfvxdixAneNp0P/kQnRmNjjwm+7naBnRb5mmtvXBaBOyr+E9gSaZ3Go4yqr7N TzcrYDCUHoDDoabuQBfh1leInNNhp5O6bcMKY= Received: by 10.204.148.85 with SMTP id o21mr4589256bkv.134.1258400853712; Mon, 16 Nov 2009 11:47:33 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 15sm55697bwz.4.2009.11.16.11.47.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 11:47:33 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B01AC53.7050207@jacaranda.org> Date: Mon, 16 Nov 2009 19:47:31 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> <4B01A041.80901@jacaranda.org> <1264410A-9D46-4395-8BF9-092CCFC7196F@acm.org> In-Reply-To: <1264410A-9D46-4395-8BF9-092CCFC7196F@acm.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig859AADEE6E1BB85EA9046C3D" Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:47:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig859AADEE6E1BB85EA9046C3D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bodo Moeller wrote: > On Nov 16, 2009, at 10:56 AM, David-Sarah Hopwood wrote: >> Martin Rex wrote: >=20 >>> And this is why it is very important that we can signal on ALL >>> future TLS connections established by a client, so that a MITM >>> can not FORCE an updated, but backwards compatible client to >>> renegotiate insecurely with an updated, but backwards compatible serv= er. >>> This is what the TLS extensions RI currently fails completely. >> >> To solve this problem, a patched RI client simply must not renegotiate= >> on a connection that is in fallback mode. >=20 > This solves the problem only if we don't allow updated servers to > perform backwards-compatible renegotiation handshakes. Right. I thought there was concensus on not allowing that? If patched servers can perform backwards-compatible renegotiation handshakes, then the attack is not fixed until *both* the client and server on a given connection are patched. If this is not allowed, OTOH, then: - the original attack (where the server sees the renegotiation) can be prevented by patching only the server; - the variant where the client sees the renegotiation (applicable only when the client fails to check the server certificate and client certs are used) can be prevented by patching only the client. Whether both or only one peer needs to be patched in order to protect a given connection, makes a very big difference to the expected time until almost all connections are protected. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig859AADEE6E1BB85EA9046C3D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksBrFsACgkQWUc8YzyzqAeK5QD+M8gFMKpROvFls0Ddp8XIJ+nO Mssgr87brlp+vWcZ5ssA/2o5qVYOg+8ufvGh7It0wibC0T0I4Yxo+7VAzgq1W+hj =Rpxg -----END PGP SIGNATURE----- --------------enig859AADEE6E1BB85EA9046C3D-- From bmoeller@acm.org Mon Nov 16 11:53:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BE33A69FE for ; Mon, 16 Nov 2009 11:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.069 X-Spam-Level: X-Spam-Status: No, score=-102.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 TSe3A+vIwibs for ; Mon, 16 Nov 2009 11:53:46 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 581273A6864 for ; Mon, 16 Nov 2009 11:53:46 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LtDrP-1OC59J1F2x-012H2F; Mon, 16 Nov 2009 20:53:35 +0100 From: Bodo Moeller To: mrex@sap.com In-Reply-To: <200911161944.nAGJi88Q022752@fs4113.wdf.sap.corp> References: <200911161944.nAGJi88Q022752@fs4113.wdf.sap.corp> Message-Id: <0483AAF8-E1E5-422B-8E9C-374EC4D16D40@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 11:53:31 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1/YiimQfe1vQ0JzzEvdi6dFNlYAlpW2EO7rooC u68qeFpCWT33lU8WkysAvON2VVdfp3HLobsvp9GLqmwneUgri2 QRrOgDl9xQ2HqifHKWw6Q== Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:53:47 -0000 On Nov 16, 2009, at 11:44 AM, Martin Rex wrote: > Bodo Moeller wrote: >> >> On Nov 16, 2009, at 10:44 AM, Martin Rex wrote: >>> I really would appreciate an extension-less negotiation through >>> ClientHello+ServerHello where the Server can confirm to the client >>> that it will do the modified finished calculation on renegotiations, >>> so that the client knows that its initial handshake can not be >>> proxied >>> into the reneogotiation of a server (will fail the finished mac if >>> done). >> I don't see why we'd want this to be extension-less for this purpose. > So that the client can signal it on EVERY SSLv3 or TLS handshake > that it can be configured to do. Currently, Browsers have either > automatic fallbacks to extension-less ClientHellos or can be > configured for SSLv3 (which is the default for MSIE) in a > comparable fashion where they send only extension-less ClientHellos, > simply because TLS extensions are known to upset servers. Sure. We want an extension-free way for clients to signal to servers that they support updated renegotiation. (We want this, that is, if we want to allow updated servers to continue to support legacy renegotiation for old clients.) However, for clients that want confirmation from the server that it's an updated server (because otherwise they wouldn't want to talk to it, suspecting it may support legacy renegotiation and thus be vulnerable), why would *this* have to be done in an extension-free way? The server-side code changes to tolerate and ignore most extensions (which is desirable anyway!) and to scan through them looking for a specific fixed extension shouldn''t really be too complicated. Bodo From marsh@extendedsubset.com Mon Nov 16 12:00:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB8A3A6AE0 for ; Mon, 16 Nov 2009 12:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 shZdbqskbMdX for ; Mon, 16 Nov 2009 12:00:50 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id A8ED63A6969 for ; Mon, 16 Nov 2009 12:00:42 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NA7kf-000JPq-7J; Mon, 16 Nov 2009 20:00:41 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C77DF667C; Mon, 16 Nov 2009 20:00:39 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+51fKW1FfX01LW7oPK/l4WpLb83m+/ivY= Message-ID: <4B01AF63.6050105@extendedsubset.com> Date: Mon, 16 Nov 2009 14:00:35 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David-Sarah Hopwood References: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> <4B01A041.80901@jacaranda.org> <1264410A-9D46-4395-8BF9-092CCFC7196F@acm.org> <4B01AC53.7050207@jacaranda.org> In-Reply-To: <4B01AC53.7050207@jacaranda.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:00:51 -0000 David-Sarah Hopwood wrote: > Bodo Moeller wrote: >> This solves the problem only if we don't allow updated servers to >> perform backwards-compatible renegotiation handshakes. > > Right. I thought there was concensus on not allowing that? > > If patched servers can perform backwards-compatible renegotiation > handshakes, then the attack is not fixed until *both* the client and > server on a given connection are patched. Unless this is allowed, servers cannot be patched before clients. There are likely more clients with less centralized administration than there are servers, so it's backwards from the way you'd want to do things. If a transition period is not allowed, people just won't patch. - Marsh From bmoeller@acm.org Mon Nov 16 12:01:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF583A6969 for ; Mon, 16 Nov 2009 12:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.08 X-Spam-Level: X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 arsPYRpWSUJd for ; Mon, 16 Nov 2009 12:01:48 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 38DFF3A67F3 for ; Mon, 16 Nov 2009 12:01:48 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M3MGG-1O0qsT2W1I-00qnxE; Mon, 16 Nov 2009 21:01:38 +0100 From: Bodo Moeller To: David-Sarah Hopwood In-Reply-To: <4B01AC53.7050207@jacaranda.org> References: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> <4B01A041.80901@jacaranda.org> <1264410A-9D46-4395-8BF9-092CCFC7196F@acm.org> <4B01AC53.7050207@jacaranda.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 12:01:34 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+vI1yCW7RgsTmxNWf99AgQam2s1B9VmkmGovx wTp3Rvylt7CN3X8jLAYQyloBK+nv1lo/WJVUSXY8tnFb4kY7/V N53uGxlPqwFaooDCKgKQw== Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:01:49 -0000 On Nov 16, 2009, at 11:47 AM, David-Sarah Hopwood wrote: > Bodo Moeller wrote: >> On Nov 16, 2009, at 10:56 AM, David-Sarah Hopwood wrote: >>> Martin Rex wrote: >>>> And this is why it is very important that we can signal on ALL >>>> future TLS connections established by a client, so that a MITM >>>> can not FORCE an updated, but backwards compatible client to >>>> renegotiate insecurely with an updated, but backwards compatible >>>> server. >>>> This is what the TLS extensions RI currently fails completely. >>> >>> To solve this problem, a patched RI client simply must not >>> renegotiate >>> on a connection that is in fallback mode. >> >> This solves the problem only if we don't allow updated servers to >> perform backwards-compatible renegotiation handshakes. > > Right. I thought there was concensus on not allowing that? Well, I'm in -- but Martin's quote above is specifically about a "updated, but backwards compatible client" talking to an "updated, but backwards compatible server". > If patched servers can perform backwards-compatible renegotiation > handshakes, then the attack is not fixed until *both* the client and > server on a given connection are patched. > > If this is not allowed, OTOH, then: > > - the original attack (where the server sees the renegotiation) can be > prevented by patching only the server; > > - the variant where the client sees the renegotiation (applicable > only when the client fails to check the server certificate and > client certs are used) can be prevented by patching only the client. > > Whether both or only one peer needs to be patched in order to protect > a given connection, makes a very big difference to the expected time > until almost all connections are protected. Yes. Note that it's more complex, though -- we'd possibly *allow* patched severs to perform backwards-compatible renegotiation, but not *require* them to do so. I'd think reasonable defaults are for *clients* to support backwards- compatible servers (although they might not actually want to perform renegotiation with them), and for *servers* to completely disallow legacy renegotiation. The question is if we'd want to allow server administrators to modify this default, and support legacy renegotiation for old clients. The problem that I see is, if we don't plan for this configuration option in the specs, some implementations might introduce it anyway, thus breaking the security that the we intend to provide. If we plan for it (such as with client-to-server signaling using a pseudo-ciphersuite number), the protocol will be more fool-proof. Bodo From bmoeller@acm.org Mon Nov 16 12:05:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3733A699E for ; Mon, 16 Nov 2009 12:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.089 X-Spam-Level: X-Spam-Status: No, score=-102.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 gwkYI3o5rV9m for ; Mon, 16 Nov 2009 12:05:12 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 89EE23A67F3 for ; Mon, 16 Nov 2009 12:05:12 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LeSUf-1NzN8R3HMz-00qlKF; Mon, 16 Nov 2009 21:05:08 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4B01AF63.6050105@extendedsubset.com> References: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> <4B01A041.80901@jacaranda.org> <1264410A-9D46-4395-8BF9-092CCFC7196F@acm.org> <4B01AC53.7050207@jacaranda.org> <4B01AF63.6050105@extendedsubset.com> Message-Id: <0B967625-01D7-4EFE-8B71-89EC2E345ACA@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 12:05:04 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+GzRM+8VrNXgqkDzavbX1P1lPX7gjNZXNFHIr dzpNU4zxeWM6F50s6hObdaR8gpEckzHt/fVvj9mXkuTECtbf78 qt36ANC0aYgvJ30pPf3yA== Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:05:13 -0000 On Nov 16, 2009, at 12:00 PM, Marsh Ray wrote: > David-Sarah Hopwood wrote: >> Bodo Moeller wrote: >>> This solves the problem only if we don't allow updated servers to >>> perform backwards-compatible renegotiation handshakes. >> Right. I thought there was concensus on not allowing that? >> >> If patched servers can perform backwards-compatible renegotiation >> handshakes, then the attack is not fixed until *both* the client and >> server on a given connection are patched. > Unless this is allowed, servers cannot be patched before clients. > There > are likely more clients with less centralized administration than > there > are servers, so it's backwards from the way you'd want to do things. Servers could be patched before clients -- it's just renegotiation that would break when an old client talks to an updated server. > If a transition period is not allowed, people just won't patch. Yup. Backwards-compatible renegotiation should be enabled just on those servers that *need* renegotiation (for the transition period). This shouldn't be the default. Bodo From mrex@sap.com Mon Nov 16 12:19:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F092F3A6991 for ; Mon, 16 Nov 2009 12:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.314, 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 eskMX3mkseRD for ; Mon, 16 Nov 2009 12:19:58 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E45A93A690E for ; Mon, 16 Nov 2009 12:19:57 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAGKJtLK023565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 21:19:55 +0100 (MET) From: Martin Rex Message-Id: <200911162019.nAGKJsNL024767@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Mon, 16 Nov 2009 21:19:54 +0100 (MET) In-Reply-To: <4B01AC53.7050207@jacaranda.org> from "David-Sarah Hopwood" at Nov 16, 9 07:47:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:19:59 -0000 David-Sarah Hopwood wrote: > > Bodo Moeller wrote: > > David-Sarah Hopwood wrote: > > > > > > To solve this problem, a patched RI client simply must not renegotiate > > > on a connection that is in fallback mode. > > > > This solves the problem only if we don't allow updated servers to > > perform backwards-compatible renegotiation handshakes. > > Right. I thought there was concensus on not allowing that? We can make it a MUST NOT only for TLSv1.3 onwards. Retroactively, we can only make it a SHOULD NOT for the installed base, because there is an installed base which we would completely brick otherwise. We must leave that decision to the consumers of the technology, and only give guidance, make it as easy as possible to adopt the necessary fix and try hard to cover as many existing usage scenarios with the fix as possible. > > If patched servers can perform backwards-compatible renegotiation > handshakes, then the attack is not fixed until *both* the client and > server on a given connection are patched. Which would indicate a design flaw in the fix. The fix I proposed will protect an updated client talking to an updated server even when both allow backwards-compatible renegotiation. If a fix is only secure if neither peer allows backwards-compatible renegotiation then the fix is definitely a failure. The purpose of the TLS handshake protection is specifically to prevent attackers from downgrading without breaking the finished macs. -Martin From marsh@extendedsubset.com Mon Nov 16 12:33:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9CE3A67B4 for ; Mon, 16 Nov 2009 12:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 LoFiiqyF9vfp for ; Mon, 16 Nov 2009 12:33:04 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id B39353A6B05 for ; Mon, 16 Nov 2009 12:33:04 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NA8Fz-000PTm-BW; Mon, 16 Nov 2009 20:33:03 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3C94E667C; Mon, 16 Nov 2009 20:33:01 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Qr80CXkus5j0SnSbVJVPGpZK+9l6kl50= Message-ID: <4B01B6F8.20203@extendedsubset.com> Date: Mon, 16 Nov 2009 14:32:56 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bodo Moeller References: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> <4B01A041.80901@jacaranda.org> <1264410A-9D46-4395-8BF9-092CCFC7196F@acm.org> <4B01AC53.7050207@jacaranda.org> <4B01AF63.6050105@extendedsubset.com> <0B967625-01D7-4EFE-8B71-89EC2E345ACA@acm.org> In-Reply-To: <0B967625-01D7-4EFE-8B71-89EC2E345ACA@acm.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:33:05 -0000 Bodo Moeller wrote: > > Servers could be patched before clients -- it's just renegotiation that > would break when an old client talks to an updated server. If it's your systems that need it, it's not "just renegotiation" it may be your entire product or mission-critical application. We may talk in terms of statistics, but for the affected systems it's a total show-stopper, that shouldn't be overlooked. - Marsh From djhopwood@googlemail.com Mon Nov 16 12:39:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BB53A680D for ; Mon, 16 Nov 2009 12:39:33 -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 PFZexvhVt+gf for ; Mon, 16 Nov 2009 12:39:32 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 4B47D3A689B for ; Mon, 16 Nov 2009 12:39:32 -0800 (PST) Received: by bwz23 with SMTP id 23so6202048bwz.29 for ; Mon, 16 Nov 2009 12:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=eqGSkxGhRn680z6q6Q/Y+9TT/JxqbCTntqQ+mvHketE=; b=TAyiB5bCIGxXrPPGfNjlViVTH8l6y3GMylt1T0mESA+MOYvtGfeOjjQ3fAT+bT7/Ja LRQA60mgnWZX7CtfO1NezQJAn7L9R7yX88zG7hXKKCQPh/5+Rrh0rSMZm1dbBFlasymM 7n+fCB71ScpO7Iz34bLHhrRw73tGX5zll0nTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=bNhDxB1ePWWhUWKY99ONtnPkajAixqbGp2W28dWN1hmORhGl2pEahXSoyywHcbQHOu i/77z4H8spHOibC2uP+cwWRx19dndnZAZiex2f48slRROLYP/WMDX8H/3+JkMJcAbl0K befsY/7pICm1YAWBhXneAQsbRQhB07eJCD4gE= Received: by 10.204.48.131 with SMTP id r3mr5093164bkf.195.1258403967054; Mon, 16 Nov 2009 12:39:27 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 31sm7323214fkt.10.2009.11.16.12.39.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 12:39:25 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B01B871.3050507@jacaranda.org> Date: Mon, 16 Nov 2009 20:39:13 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911161029.nAGAT8uN019401@fs4113.wdf.sap.corp> <4B01923F.9020806@pobox.com> <4B019434.9020001@extendedsubset.com> <4B019BC7.2080201@pobox.com> In-Reply-To: <4B019BC7.2080201@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5C392642F3C2E14E5A2C07F2" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:39:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C392642F3C2E14E5A2C07F2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > If a client doesn't check the server's certificate, it is subject to > any man-in-the-middle attack. One of the requirements is that a client= > verify the certificate. If a client doesn't do that, how can we > possibly protect it??? The important case here is where client certificates are involved. Normally, a MITM would not be able to authenticate its connection to the server using a client cert held by the actual client -- that cert authenticates only the connection from client to MITM, and replaying the CertificateVerify message (in the case of a client cert with signing ability) does not work. Therefore, the form of the attack described by Marsh does break a security property that TLS is intended to guarantee, independent of any checking by the client of the server certificate. Does anyone use "fixed_dh" client certs that lack signing ability, BTW? --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig5C392642F3C2E14E5A2C07F2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksBuIMACgkQWUc8YzyzqAe4HQD8CTRF23WilmkPn7ggltGIPW8+ 6et0/nKY/htaFcEPxhsA/jgGiFIMnuwbWCWfnIqL/JN/57e/xYxlMzz42ip12TGc =rF/I -----END PGP SIGNATURE----- --------------enig5C392642F3C2E14E5A2C07F2-- From yngve@opera.com Mon Nov 16 13:41:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBF13A69F8 for ; Mon, 16 Nov 2009 13:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 7-A2dNr1jjkz for ; Mon, 16 Nov 2009 13:41:23 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id C393B3A69FA for ; Mon, 16 Nov 2009 13:41:22 -0800 (PST) Received: from acorna.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAGLe8sj003190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Nov 2009 21:40:09 GMT Date: Mon, 16 Nov 2009 22:41:17 +0100 To: tls@ietf.org From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera Mail/9.65 (Win32) Subject: [TLS] Suggestions regarding renego extensions, for present, future and old implementations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:41:24 -0000 Hello all, I've noticed there has been various suggestions about how one should add a signaling mechanism for clients and servers that does not support extensions in their current implementation. As I understand it, the sticky point have been how the server can signal its patched status back to the client, so that both sides can be assured that the other end is patched and will use a secure renegotiation procedure. Below is a suggestion for how to solve this problem. Before I handle the older implementations I would like to suggest the following regarding the RI extension: 1. The RI extension becomes mandatory for TLS 1.0 -> TLS 1.2 (inclusive) for handshakes that support Extensions at both ends 2. That TLS 1.3+ handshakes ignore the RI Extension and instead automatically include data from the previous handshake on the connection, e.g. the finished messages as in the RI system, when calculating the finished messages, and other values, with the first handshake using a 0x00 sequence matching the normal length of the value used in the calculation. These values should be included at some point in the handshake hash; either as a prefix or a postfix (I suspect a prefix may be easier to implement, the values are known as the handshake starts, and hashing can't start until the protocol version is known, anyway). Clients that know the server supports TLS 1.3 SHOULD NOT send the RI extension. Regarding older implementations, since they have to be patched significantly anyway (if they are to be patched), I would suggest the following: A. The client signals patched status in a field that should not cause any trouble for servers; the suggested reserved cipher suite should be suitable for this B. This signal is, as far as the handshake is concerned, handled as if the client sent an RI extension field, so C. The server responds with an RI extension in the ServerHello, using the format specified for Extensions, using the finished messages from the previous negotiation on the connection, as specified in EKR's draft. D. When receiving the RI extension, the client must check that the values match what it expects, as with the RI, and fail the handshake if there is a mismatch E0. The Client then includes its finished data in the finished calculation at some point, possibly just by including it in the handshake hash after the ServerHello message, or concatenating it after all the other data before calculating the values that depend on the handshake hash. E1. An alternative to E0 is that a ciphersuite range is set aside to encode the entire client finished message as a sequence of "cipher suites", e.g (using 0xFE as a example) (0xFE, len=N), (0xFE, fin00) (0xFE, fin01) (0xFE, fin02) ... (0xFE, fin0N). Use of the ciphersuite series would then indicate the client's patched status, and it is automatically included in the handshake hash. The drawback is that this will make a range of 256 ciphersuite codepoints unavailable for future use. First handshake would code (0xFE, 0x00), the second for a 12 byte message (0xFE, 0x0C) (0xFE, fin0) ... (0xFE, finC). The sequence MUST be place at the end of the ciphersuite list. NOTE: A patched server that supports Extensions in the ClientHello MUST use that extension in the response, and ignore the fallback signal. Clients that detect that the server supports the RI extension directly SHOULD avoid sending the fallback signal in later handshakes. IMO A-E should be relatively easy to implement both in clients and servers. Servers that normally does not support extension should be able to easily code the extension sequence and append it, and patched clients that does not support extensions normally should also be able to decode it easily, tough they should make sure they can read multiple extensions (just in case we have to do this again sometime) The big issue I expect is the use of an extension in a Serverhello not preceded by a ClientHello using the extension is a departure from what is mandated by the Extension RFC. I think it can be defended as an exception due to the severity of this particular issue. As mentioned in B the idea is to consider the fallback signal as the extension. It is possible that the extension ID in C should have a different assigned number than the normal RI extentsion so that clients that send both the extension and the fallback signal can tell which type of server they are negotiating with. This is particularly important if the background calculation update is used, instead of the ciphersuite finished message sequence, but IMO the client and server should use method 1 if they can, and method 2 when they are both TLS 1.3+ implementations. A benefit of point C is that we avoid trying to modify exisiting ServerHello fields to something they were never designed for, and which might conceivably cause other problems. And alternative to using the Extension in point C could be to allocate a separate handshake message sent immediately after the ServerHello (or at some other point before the HelloDone message), but I suspect that this would be more troublesome in some client implementation designs than looking for the extension sequence. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From bmoeller@acm.org Mon Nov 16 13:59:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE2F3A68D0 for ; Mon, 16 Nov 2009 13:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 DPnLyLYIINzi for ; Mon, 16 Nov 2009 13:59:38 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 49F2D3A6878 for ; Mon, 16 Nov 2009 13:59:38 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LtlI5-1OAPHI31nR-011itH; Mon, 16 Nov 2009 22:59:31 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4B01B6F8.20203@extendedsubset.com> References: <200911161653.nAGGr1X6012322@fs4113.wdf.sap.corp> <4B01A041.80901@jacaranda.org> <1264410A-9D46-4395-8BF9-092CCFC7196F@acm.org> <4B01AC53.7050207@jacaranda.org> <4B01AF63.6050105@extendedsubset.com> <0B967625-01D7-4EFE-8B71-89EC2E345ACA@acm.org> <4B01B6F8.20203@extendedsubset.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 13:59:27 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+rDtG/uSs4osqPCES6v2rdBfdVOw4dOT5r8pF f1gCE8q2Y9eDwj62fjayzgQD0lImwaRAnrSeA8YLqct+ygg9YG IrBmZ1rtp5xn3ZL808i5Q== Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:59:39 -0000 On Nov 16, 2009, at 12:32 PM, Marsh Ray wrote: > Bodo Moeller wrote: >> Servers could be patched before clients -- it's just renegotiation >> that >> would break when an old client talks to an updated server. > > If it's your systems that need it, it's not "just renegotiation" it > may > be your entire product or mission-critical application. > > We may talk in terms of statistics, but for the affected systems > it's a > total show-stopper, that shouldn't be overlooked. Sure. My point was that it's exaggerated to claim that "Unless this is allowed, servers cannot be patched before clients". Server could be patched before clients; just servers that need renegotiation couldn't be patched before clients. However, I agree that even this interoperability case needs to be taken seriously. I wouldn't want legacy renegotiation to be enabled in updated servers by default -- normally I'd want to see this disabled so that once all servers have been updated, the security problem will be resolved. If a server operator decides to accept the price of accepting legacy renegotiation, the specs should cater for this in a way such that there's no downgrade attack if an updated but lenient clients talks to an updated but lenient server (which implies that the client has to send some signal in the Client Hello, or elsewhere in the handshake); and such that an updated but lenient client doesn't have to send an extension in the initial handshake (i.e., said signal will have to be something other than an extension) or even in a renegotiation handshake unless it has established that it's talking to an updated server. The latter indeed suggests we need a signal from the server back to the client to confirm that it's updated. Here's a rather specific proposal, which I think doesn't agree 100% with anything that has previously been proposed, although certainly all the bits and pieces come from the various proposals that are around. If the client's "I am updated" signal to the server is a pseudo ciphersuite (to avoid having to send an extension and breaking interoperability with older servers), I don't see why the server's "I am updated too" signal back to the client couldn't be an extension in any case. The TLS Extensions specs don't allow the server to send extensions that haven't been proposed by the client -- that's somewhat broken to start with (we really just wouldn't want the server to send any extensions to a client that doesn't know *anything* about extensions), but we can certainly override this rule for this specific case, where the client opts in by sending its own signal. The client and server wouldn't have to know anything else about extensions. If the client doesn't, the server_hello_extension_list it sees in the Server Hello in this scheme would always correspond to a fixed encoding, which is trivial to handle. If the server doesn't, it would only have to generate this fixed encoding, which is just as trivial. If updated clients send the pseudo ciphersuite in every Client Hello, and updated servers send the (empty) extension in every Server Hello responding to such a Client Hello, both parties have enough information to detect when they are both updated. For this case, we'll have to change the definition of the Finished messages. My preferred approach is (following the suggestion by Martin Rex) to include the previous handshake's Finished messages into handshake_messages if it's a renegotiation handshake (as "virtual handshake messages" -- maybe I'd rather call them "silent handshake messages", or just "remembered handshake messages" to better capture the specific scenario). For an initial handshake, nothing needs to be changed, except that some updated clients might be configured to refuse to complete a handshake with any server that hasn't been updated (just like most updated servers should be configured to refuse to complete a renegotiation handshake with any client that hasn't been updated). Updated clients and servers should probably send their signals in *all* handshakes: (a) initial handshakes and (b) legacy renegotiation handshakes are a must, but I think requiring them too in (c) updated renegotiation handshakes makes things easier to get right. We'd get rid of the signals from a specific protocol version on: If the client and server agree on that version, the new renegotiation Finished computation would be implied. If the client is offering interoperability with earlier protocol versions, it should still send the explicit signal. Bodo From peter.robinson@rsa.com Mon Nov 16 14:47:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396863A6839 for ; Mon, 16 Nov 2009 14:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 gDf-4nsDKfW3 for ; Mon, 16 Nov 2009 14:47:57 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 534483A6821 for ; Mon, 16 Nov 2009 14:47:57 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nAGMlnXs017822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 17:47:49 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 16 Nov 2009 17:47:40 -0500 Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2mp) with ESMTP id nAGMldMi021058; Mon, 16 Nov 2009 17:47:39 -0500 Received: from CORPUSMX100B.corp.emc.com ([128.222.76.52]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 17:47:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Nov 2009 17:47:36 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_08D5_01CA6762.9C7FFD50" Message-ID: In-Reply-To: <1b587cab0911152138q613aa1f5o492f856f2486a185@mail.gmail.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [TLS] RSA BSAFE TLS Interoperability Server Thread-Index: Acpmfvq8RfaXwj48Re+1IDIUPhm8+QAjvbAg References: <4B008F6D.7070303@pobox.com> <4B00AE09.8050906@jacaranda.org> <4B00D699.7030902@pobox.com> <1b587cab0911152138q613aa1f5o492f856f2486a185@mail.gmail.com> From: To: X-OriginalArrivalTime: 16 Nov 2009 22:47:38.0487 (UTC) FILETIME=[CC18F070:01CA670E] X-EMM-EM: Active Cc: kathy.kriese@rsa.com, tls@ietf.org Subject: Re: [TLS] RSA BSAFE TLS Interoperability Server X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 22:47:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_08D5_01CA6762.9C7FFD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >>RSA, The Security Division of EMC, has created a >>TLS Interoperability Server to allow inter-op >>testing of TLS. >Does it support the renegotiation extension? Yes it does. ------=_NextPart_000_08D5_01CA6762.9C7FFD50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWmzCCAucw ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1 s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5 IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3 Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/ eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5 /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1 cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13 qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggR+MIID56ADAgECAhEAsSe9 yNTH2rYKRiN7F8KhkTANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT MB4XDTA5MDcyMTA1MTYxM1oXDTExMDcyMjA1MTYxM1owgekxEzARBgoJkiaJk/IsZAEZFgNjb20x EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjEMMAoGA1UECxMD UlNBMRUwEwYDVQQLEwxBc2lhL1BhY2lmaWMxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQF EwYwNjQ4MTQxFzAVBgoJkiaJk/IsZAEBEwdyb2JpbnAyMRcwFQYDVQQDEw5QZXRlciBSb2JpbnNv bjElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA2CcjIV2QNoJP4YbPejhZX2MSu53/EooTnrkf7M4gsl1DobXkk3CO6kU9bN6O wwL/o87dQ4y2FHjwkV4WeoodhvZa08q5uX4vZCtB2Hn0OUrbPzyKl7wXSq+yezKCQJBrVCTwWjKK A6Gqc1VhkqWSBCpUaQ39TsVDxNYCGIn433cCAwEAAaOCAX8wggF7MIGSBgNVHSAEgYowgYcwgYQG CSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5o dG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9y YXRlZCBieSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnBldGVyLnJvYmluc29uQHJzYS5jb20wDgYDVR0PAQH/BAQDAgeAMEYG A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQm 7p962rS9dUpGeQZt+Vi1su6tQTANBgkqhkiG9w0BAQUFAAOBgQCghPP5wxcDJuACPYJ/U1sjhyE4 gxpGKZNPnnDcjfHo+Cq87cWawpV5Rzpg8KVZc0EoG6BabGNyk+WgZMjCzADpg+appN4cX+DML0ir 3cBcX8pQTuKw1VRlUjidjkTIl/Z2hrcvgh2lJG+PFV2ogWICzwOj4/zKG4khs9VO5NNPezCCBI4w ggP3oAMCAQICEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFS U0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xh c3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czELMAkGA1UEBhMCVVMwHhcNMDkwNzIxMDUxNjE4WhcNMTEwNzIyMDUxMzM2WjCB7TETMBEGCgmS JomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0 aW9uMQwwCgYDVQQLEwNSU0ExFTATBgNVBAsTDEFzaWEvUGFjaWZpYzEUMBIGA1UECxMLRW5naW5l ZXJpbmcxDzANBgNVBAUTBjA2NDgxNDEXMBUGCgmSJomT8ixkAQETB3JvYmlucDIxGzAZBgNVBAMT ElBldGVyIFJvYmluc29uLUVuYzElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqeM4888BmvaveugOJqTYWGNm3cTP6qJe444S 7AJaXDnKZlt1cJByB+B83hdGGe2FyRQGGef0DNZhQIfaa41dzZbDWuogZ3mKxyuOhciZSoRoCIM0 jlPh5vqhDmXBPFQ/EedNPRk+tl+mKVz2fHbsI01bWtueV05BvJu330cj0WUCAwEAAaOCAYswggGH MDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDCB kgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwUwdzAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNl Y3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMC AQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCEGA1UdEQQaMBiBFnBldGVyLnJvYmlu c29uQHJzYS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206 ODAvUlNBQ2xhc3MyUGVyc29uYWxDQS5jcmwwHwYDVR0jBBgwFoAUxpPuxqX+41WOz4ojH+6Y3iHy n6cwHQYDVR0OBBYEFGg/pAQlQSo2dvZeyryhS2toL395MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG 9w0BAQUFAAOBgQCY/nGMkd29x8wULeVsTP+emR/XVn+LqcfwzgwpUSKP1FX1WedrHwlNKFaVDjQX FaNETkV4XzMugf4iafsgZUp5DmzIOBB5H5MI1k+CprZ0tjet7gcN0sdCt0fggfw44GZ37rwxzwyt XZrbEePtb8wFYVEobKBD/ZqvghavL93K3DGCA4EwggN9AgEBMIGiMIGMMRowGAYDVQQKExFSU0Eg U2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3Mg MiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEL MAkGA1UEBhMCVVMCEQCxJ73I1MfatgpGI3sXwqGRMAkGBSsOAwIaBQCgggI0MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExNjIyNDczNlowIwYJKoZIhvcNAQkE MRYEFApVJWSmmHRkQQgqxzd4s4dLrupdMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA vl+zPI12IIUYbqURFw5yZjWgs8BVd1X7EI5f4YdVYUWo4SaVglOrx3icj7Jq59CATP7dbHtUH7Oa gXw9VMi5RWAdLx1aV4sj3W7Ze76I3SBOmdhUUHJOLRyvHNmBh7itz0lN73LbeMnw7sKIySgwfz+o 6mPXI50804Q8qOcQb9kAAAAAAAA= ------=_NextPart_000_08D5_01CA6762.9C7FFD50-- From mrex@sap.com Mon Nov 16 15:09:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB113A67B0 for ; Mon, 16 Nov 2009 15:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 7dr0SKlkctwR for ; Mon, 16 Nov 2009 15:09:23 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 097313A687D for ; Mon, 16 Nov 2009 15:09:22 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAGN9J1r007459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 00:09:19 +0100 (MET) From: Martin Rex Message-Id: <200911162309.nAGN9IZK005017@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Tue, 17 Nov 2009 00:09:18 +0100 (MET) In-Reply-To: from "Yngve N. Pettersen" at Nov 16, 9 10:41:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Suggestions regarding renego extensions, for present, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:09:24 -0000 Yngve N. Pettersen wrote: > > Regarding older implementations, since they have to be patched > significantly anyway (if they are to be patched), I would suggest the > following: > > A. The client signals patched status in a field that should not cause any > trouble for servers; the suggested reserved cipher suite should be > suitable for this > > B. This signal is, as far as the handshake is concerned, handled as if > the client sent an RI extension field, so > > C. The server responds with an RI extension in the ServerHello, using the > format specified for Extensions, using the finished messages from the > previous negotiation on the connection, as specified in EKR's draft. One signaling mechanism that works for all is perfectly sufficient. Two different signaling mechanism for the same purpose adds complexity without value, and significantly complicates interop testing. The signaling mechanism that can be blindly asserted, even when performing extension-less ClientHello fallbacks as currently implemented on Vista and in Firefox 3.5, reduces complexity. When I suggested that the client always signals with a specially assigned ciphersuite ID and the server should always respond with a ServerExtension even when the client didn't send one, I received strong opposition, since this would violate existing rules for TLS extensions. I agree that this would be a significant change and might require non-trivial changes to generic functions that deal with TLS extensions processing in existing code. >From a protocol perspective, however, I do not see a problem. Just look at the one mandatory-to-implement TLS extension in TLSv1.2 and its extremely weird implemenation and processing rules: - MUST be implemented by server - MAY be omitted by client using only default sig/hash algorithms - MUST be sent by client not capable/willing of default sig/hash algorithms - MUST NOT be sent by client proposing TLSv1.1 or older - MUST NOT be sent back in ServerHello Looking at this mess, I'm wondering why this extension was deliberatly crippled to not work with TLSv1.1. Do we really want our TLS implementations to replace negotiation by assumptions when someone pulls the plug on SHA-1 based signatures? I think it was previously mentioned on this list that the answer is, that the Server reply for the signature_algorithms is through the CertificateRequest message instead of a ServerHello extension (a protocol change not known to TLSv1.1). Bottom line, this would not be the first time that TLS extensions are mutilated, TLSv1.2 signature_algorithms has set precedent already. :-/ > > 2. That TLS 1.3+ handshakes ignore the RI Extension and instead > automatically include data from the previous handshake on the connection, > e.g. the finished messages as in the RI system, when calculating the > finished messages, and other values, with the first handshake using a 0x00 > sequence matching the normal length of the value used in the calculation. > These values should be included at some point in the handshake hash; > either as a prefix or a postfix (I suspect a prefix may be easier to > implement, the values are known as the handshake starts, and hashing can't > start until the protocol version is known, anyway). Clients that know the > server supports TLS 1.3 SHOULD NOT send the RI extension. Why not just change the finished calculation right away for all existing protocol versions including SSLv3 and get rid of the TLS extension on the renegotiation handshake entirely. That is going to save many lines of code, network bandwidth, protcol complexity and pages in the TLSv1.3 spec describing this additional complexity. > > E0. The Client then includes its finished data in the finished > calculation at some point, possibly just by including it in the handshake > hash after the ServerHello message, or concatenating it after all the > other data before calculating the values that depend on the handshake hash. Perfectly sufficient. There is no need to send the verify_data of the finished messages over the wire. The verify_data of the previous finished messages should go into the handshake message hash always directly after ServerHello, so that it affects to CertificateVerify as well as other/future protocol extensions that want to add additional handshake messages and might want to also use the handshake message hash. ClientHello and ServerHello is the negotiation mechanism for the TLS base protocol (plus TLS extensions). It is fairly unlikely that any future protocol update will add handshake messages before them and also unlikely that any future protocl update will remove ServerHello. > > E1. An alternative to E0 is that a ciphersuite range is set aside to > encode the entire client finished message as a sequence of "cipher > suites", e.g (using 0xFE as a example) (0xFE, len=N), (0xFE, fin00) > (0xFE, fin01) (0xFE, fin02) ... (0xFE, fin0N). Use of the ciphersuite > series would then indicate the client's patched status, and it is > automatically included in the handshake hash. The drawback is that this > will make a range of 256 ciphersuite codepoints unavailable for future > use. First handshake would code (0xFE, 0x00), the second for a 12 byte > message (0xFE, 0x0C) (0xFE, fin0) ... (0xFE, finC). The sequence MUST be > place at the end of the ciphersuite list. Please DON'T. I received the suggestion to have two special ciphersuites assigned rather than one. One to signal that the client is updated and the other to signal whether the client is performing an initial handshake. While this might sound nice, I do not believe it to really help anything. The data in the plaintext phase of the handshake (i.e. all of ClientHello and ServerHello) can be arbitrarily doctored by the MitM, and the communication peers can only detect such doctoring when comparing their handshake hashes, during verification of the finished messasges, and additionally during CertificateVerify when client-authentication is used. If the finished message verification fails, it is difficult to tell what caused it. If we are debugging in a controlled environment, such status indicators might help determining the cause. In the presence of an attacker, everything is just a wild guess. I consider it somewhat unlikely that a clients initial handshake is proxied into a server renegotiation "by accident" and needs this additional debugging hint. ;-) -Martin From bmoeller@acm.org Mon Nov 16 15:25:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202A93A67E5 for ; Mon, 16 Nov 2009 15:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 j6VFhhF6BQzM for ; Mon, 16 Nov 2009 15:25:10 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by core3.amsl.com (Postfix) with ESMTP id 10BC73A679C for ; Mon, 16 Nov 2009 15:25:10 -0800 (PST) Received: from dhcp-172-19-7-81.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MRybG-1NdHJm2UfK-00TeFY; Tue, 17 Nov 2009 00:25:02 +0100 From: Bodo Moeller To: mrex@sap.com In-Reply-To: <200911162309.nAGN9IZK005017@fs4113.wdf.sap.corp> References: <200911162309.nAGN9IZK005017@fs4113.wdf.sap.corp> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 15:24:58 -0800 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX18XNn0Vzg9S/akTc4hvuVaKx5YUEJVyKucVO+M Z5JCN35UvqdI41UgpQ8Hw5deXqb1NHzfsksbQYb2L+uVAdIVu/ 7vzP+71xtJ0uWAiaZxixA== Cc: tls@ietf.org Subject: Re: [TLS] Suggestions regarding renego extensions, for present, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:25:11 -0000 [This message is really just saying "I agree" a lot. Those who are just interested in seeing new arguments can safely skip it.] On Nov 16, 2009, at 3:09 PM, Martin Rex wrote: > One signaling mechanism that works for all is perfectly sufficient. I agree. > When I suggested that the client always signals with a specially > assigned > ciphersuite ID and the server should always respond with a > ServerExtension > even when the client didn't send one, I received strong opposition, > since this would violate existing rules for TLS extensions. > > I agree that this would be a significant change and might require > non-trivial changes to generic functions that deal with > TLS extensions processing in existing code. > > From a protocol perspective, however, I do not see a problem. Me neither. Do we have any implementors who are worried about changes to existing code for TLS extension processing? Yes, the change would introduce a new special case, but would this ever really be hard to handle? > Why not just change the finished calculation right away for all > existing > protocol versions including SSLv3 and get rid of the TLS extension > on the renegotiation handshake entirely. That is going to save > many lines of code, network bandwidth, protcol complexity and > pages in the TLSv1.3 spec describing this additional complexity. I agree. We can just change the Finished calculation for handshakes where both parties send the signals indicating they support the updated protocol (e.g. said special ciphersuite ID, and said new server-side extension [which wouldn't have to carry any content, unlike in the current Renegotiation_Info proposal]). >> E0. The Client then includes its finished data in the finished >> calculation at some point, possibly just by including it in the >> handshake >> hash after the ServerHello message, or concatenating it after all the >> other data before calculating the values that depend on the >> handshake hash. > > Perfectly sufficient. There is no need to send the verify_data > of the finished messages over the wire. > > The verify_data of the previous finished messages should go into the > handshake message hash always directly after ServerHello, so that it > affects to CertificateVerify as well as other/future protocol > extensions > that want to add additional handshake messages and might want to also > use the handshake message hash. > > ClientHello and ServerHello is the negotiation mechanism for the > TLS base protocol (plus TLS extensions). It is fairly unlikely that > any future protocol update will add handshake messages before them > and also unlikely that any future protocl update will remove > ServerHello. Any new protocol version with such changes (which are very unlikely to begin with) would just have to define its own way of computing Finished messages such that the previous Finished messages are taken into account. > I received the suggestion to have two special ciphersuites assigned > rather than one. One to signal that the client is updated and the > other to signal whether the client is performing an initial handshake. > > While this might sound nice, I do not believe it to really help > anything. I agree. Bodo From djhopwood@googlemail.com Mon Nov 16 15:50:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E003A6AA4 for ; Mon, 16 Nov 2009 15:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, SARE_OBFU_CODEINE=0.833] 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 JuDRMmzLCAe5 for ; Mon, 16 Nov 2009 15:50:43 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 0EA453A6995 for ; Mon, 16 Nov 2009 15:50:42 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so2129248eyd.51 for ; Mon, 16 Nov 2009 15:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=DLsL/SwBHx5cogxyh34X1JuNaFVxynSqEXCo/bOvoTU=; b=SCkoPq7TxJLx0ro1UmVCSuphFNuETW/UtbefbkOjNkyvXYFyCpNWyjNAlm139SMri2 XGjL75tynvlQsQD/FSr51AQcTXnk0Bu+ZEs1RPiVBG4PMj2D42kSayLYZLWTVJWlzt4u MfSIYCRJsfZknpncwwTGvwhwM4AZkX2Y5TZj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=txT8FGDPtJYkG0gbxX/OcT9pCiA1nXGkfBlrPBwadmE8Me3dcgu0kqjf+AylY97sj8 X50Q+xKueIbh7Czv55OEZUU3VqPCazLmWzc+dto7Kox/nVjithdRogZqFG3OOW4ZDLZV apzEbEmwnvnYY3+AoriqaGKPZUxO9eEENh6pM= Received: by 10.213.100.11 with SMTP id w11mr1704812ebn.34.1258415439018; Mon, 16 Nov 2009 15:50:39 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 23sm7435945eya.28.2009.11.16.15.50.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 15:50:37 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B01E547.4080704@jacaranda.org> Date: Mon, 16 Nov 2009 23:50:31 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <20091116113424.ED8DA69F8DC@kilo.networkresonance.com> <20091116143709.737C869F989@kilo.networkresonance.com> In-Reply-To: <20091116143709.737C869F989@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig6F2C8631B78627874F2D1C2A" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:50:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F2C8631B78627874F2D1C2A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > At Mon, 16 Nov 2009 15:20:00 +0100 (MET), > Martin Rex wrote: >> Please consider that you are asking a lot of other implementors, >> who do not have an implementation yet, and many of which are not >> actually vulnerable to the problem, to implement this. >=20 > I'm not saying any such thing. If you're not willing to do=20 > server side renegotiation I think it's perfectly appropriate > to make no changes to your implementation. Note that if a server makes no changes, then strict clients will refuse to connect to it, even on an initial handshake. So *all* servers that need to be interoperable with strict clients necessarily have to be changed. This applies to any possible fix that supports the strict client policy. (Attempting to detect whether a server supports renegotiation by trying to renegotiate, doesn't work, because: - an attacker can force a renegotiation failure; - the server might only reject unsolicited renegotiations; - if the client detects a non-renegotiating server and then reconnects, it has no assurance that the server it reconnects to is the same one -- consider wildcard certificates for instance.) >> For them, the difference between a TLS extension RI and a much >> smaller and more efficient extension-less solution can be >> very significant -- in particular when it comes to testing >> the server-side of the generic extensions handling. >> >> The amount of code changes for the extension-less solution is >> rather small, this is _NOT_ going to be a burden for the >> implementors that have experimenting with TLS extension RI. >> It will be LESS than a day of work for each codeline. >=20 > Yes, as I said above I consider the entire implementation effort > issue to be a complete red herring. I was merely observing > that if one takes it seriously it's not clear that it actually > cuts in the direction you are arguing. I agree completely; the implementation effort for approaches using extensions is not significantly greater than for any other signalling mechanism. For the subset of implementations that already support extensions, it is less. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig6F2C8631B78627874F2D1C2A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksB5VEACgkQWUc8YzyzqAcmdgD+I82EZOLGUuqvq3kILFA2ZKDQ R5VyggJPZsLAHbwLx+oBAJPj8bW7LBgLjqpDxPQx8durJHPQCTUOcbDoEIhVk074 =+MqL -----END PGP SIGNATURE----- --------------enig6F2C8631B78627874F2D1C2A-- From mrex@sap.com Mon Nov 16 16:08:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22093A6A47 for ; Mon, 16 Nov 2009 16:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.287, 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 9U5-ImVCTOlN for ; Mon, 16 Nov 2009 16:08:40 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id EE9A93A6811 for ; Mon, 16 Nov 2009 16:08:39 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAH08bjF025351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 01:08:37 +0100 (MET) From: Martin Rex Message-Id: <200911170008.nAH08bNp008572@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Tue, 17 Nov 2009 01:08:37 +0100 (MET) In-Reply-To: <4B01E547.4080704@jacaranda.org> from "David-Sarah Hopwood" at Nov 16, 9 11:50:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 00:08:41 -0000 David-Sarah Hopwood wrote: > > I agree completely; the implementation effort for approaches > using extensions is not significantly greater than for any other > signalling mechanism. For the subset of implementations that > already support extensions, it is less. Looking at the code for TLS extensions in openssl-0.9.8g your statement seems wrong. It's more. And if a codebase doesn't have extensions yet, it is significantly more, because extensions is a generic container and there may be more than one. The latter is also a reason why interop testing becomes a magnitude more complex, because you need to interop-test a huger number of possible combinations. Not necessarily for existing extensions code, but definitely for extensions code that needs to be implemented first time just for this fix. It is extremely unwise to ask especially the maintainers of _old_ code, who are most likely not even vulnerable (lacking server-side renegotiation entirely), to add generic TLS extensions code and build themselves a test client that can simulate all the various combinations possible with TLS extensions in order to test they're processing it correctly. -Martin From yngve@opera.com Mon Nov 16 16:14:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CF83A6A1F for ; Mon, 16 Nov 2009 16:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 3toEdJ9cqsd4 for ; Mon, 16 Nov 2009 16:14:49 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id B0A403A6933 for ; Mon, 16 Nov 2009 16:14:48 -0800 (PST) Received: from acorna.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAH0DSRB007978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 00:13:34 GMT Date: Tue, 17 Nov 2009 01:14:38 +0100 To: mrex@sap.com From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <200911162309.nAGN9IZK005017@fs4113.wdf.sap.corp> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200911162309.nAGN9IZK005017@fs4113.wdf.sap.corp> User-Agent: Opera Mail/9.65 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] Suggestions regarding renego extensions, for present, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 00:14:50 -0000 On Tue, 17 Nov 2009 00:09:18 +0100, Martin Rex wrote: >> 2. That TLS 1.3+ handshakes ignore the RI Extension and instead >> automatically include data from the previous handshake on the >> connection, >> e.g. the finished messages as in the RI system, when calculating the >> finished messages, and other values, with the first handshake using a >> 0x00 >> sequence matching the normal length of the value used in the >> calculation. >> These values should be included at some point in the handshake hash; >> either as a prefix or a postfix (I suspect a prefix may be easier to >> implement, the values are known as the handshake starts, and hashing >> can't >> start until the protocol version is known, anyway). Clients that know >> the >> server supports TLS 1.3 SHOULD NOT send the RI extension. > > Why not just change the finished calculation right away for all existing > protocol versions including SSLv3 and get rid of the TLS extension > on the renegotiation handshake entirely. That is going to save > many lines of code, network bandwidth, protcol complexity and > pages in the TLSv1.3 spec describing this additional complexity. The reason for not just changing the finished calculation in the background for pre-TLS 1.3 is that clients and servers using TLS 1.2 and earlier (including SSLv3) must be able to tell, during the *first* handshake, whether or not the other side is using the safe renegotiation method, while still being able to complete negotiation with an unpatched client or server during a transition period. IMO The best way to accomplish that goal (in pre-TLS 1.3) is by including the chaining information in the handshake through the handshake messages. The question is how? My preference is to use the RI extension whenever possible in pre-TLS 1.3, since it is cleaner protocol-wise, with a fallback option on the client side if extensions are, or may be unavailable. I think most of the logic in pre-TLS 1.3 will surround the decisions to send and detect the fallback, the data of which would then be passed on to the RI processing (case E1), there would be little or no logic in the Finished message processing that is not required by the RI extension. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From mike-list@pobox.com Mon Nov 16 16:34:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C50B3A697A for ; Mon, 16 Nov 2009 16:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 nyB1+hgXZSnB for ; Mon, 16 Nov 2009 16:34:14 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 2F3153A682B for ; Mon, 16 Nov 2009 16:34:14 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id EA7679F9F7 for ; Mon, 16 Nov 2009 19:34:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=2Kj218ZTGzTV3yz9hCyYUJgQe LA=; b=AeLfSlRAddNCQQTR6S61Ny3DWtKdP2aG8ixKGT48TPsX23Ggmwk9xKPIB g6SR3/AYaUf9BO70cvDoKfk9gkmkvledeUhpUo3vGnSJ+Je3yAL2Sku7wtSVOlbH D0wDJWsj0Gf12kgPEac9WrsA1z/sLmIlmB4agRDxVl3buTMu8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=egvxu/hC86NyIa1tO5m W/TdDh9KHPpCKhIgltPDOlJF3ZPyuC0u/IBUICdUqifYPvUOlbTp4w45AWsve4Dc OBd186GVKWPIwrcNtE5ljilXW7AXSy+Cxh5KfaHA5ycaXyRZMFrtTHYe/zi3bIXf VPmER3rC5VG6DxIdg+T0ft1I= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E66E59F9F6 for ; Mon, 16 Nov 2009 19:34:12 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 775C29F9F3 for ; Mon, 16 Nov 2009 19:34:12 -0500 (EST) Message-ID: <4B01EFC4.70900@pobox.com> Date: Mon, 16 Nov 2009 16:35:16 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: EDB9D078-D310-11DE-9D2C-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 00:34:15 -0000 This proposed solution is a summary of many ideas from the list, but with a twist: the server can send an alert message to the client (I realize it's not included in the handshake hash but that doesn't matter -- see below). We all seem to agree that the flaw is due to a problem with the Finished calculation. If only it had included some info from previous handshakes, this problem would not exist. So to fix that, we can add a "virtual" handshake message such as this: struct { opaque previous_client_verify_data<0..255>; opaque previous_server_verify_data<0..255>; } PreviousVerifyData; Where exactly this gets inserted into the stream of handshake messages doesn't matter to me. The important feature is that it will always include at least two bytes, so it is not compatible with current Finished calculations. Then all that is needed is a way for a client and server to signal their support. Using a magic cipher suite is the most interoperable thing the client can send since servers already have code to process a variable-length list. We could add a requirement that this magic cipher suite MUST be the first in the list to make the server code simpler. Upon receiving the magic cipher suite, the server would send a Warning alert (with a new number) to signal to the client that it will use the new Finished calculation. This MUST be sent before ServerHello. When the client receives the alert, it switches to the new Finished calculation as well. A MITM can not mess with this successfully. If it removes the magic cipher suite, the old Finished calculation will be used by both the client and server, but since the server's handshake messages are not the same as the client's, the handshake will fail. If it lets the magic cipher suite get to the server, but blocks the alert message, then the server will be using the new Finished calculation while the client uses the old, so that handshake will fail too. I'm pretty sure that both sides can detect this tampering, if they put in the effort, but I haven't thought through it sufficiently. Since the only bits on the wire change is an additional cipher suite, servers will not have a problem with it. Failure to handshake should not cause fall back behavior (i.e. retrying without the cipher suite). The only thing I don't like is that by blocking the alert message, a MITM can cause denial of service to a "strict" client. But they can deny service in many other ways, so this is probably not important. Mike From djhopwood@googlemail.com Mon Nov 16 16:36:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE763A682B for ; Mon, 16 Nov 2009 16:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 iOY9VfxU4tQs for ; Mon, 16 Nov 2009 16:36:19 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 15E313A6811 for ; Mon, 16 Nov 2009 16:36:18 -0800 (PST) Received: by bwz23 with SMTP id 23so6423021bwz.29 for ; Mon, 16 Nov 2009 16:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=xuMc0dcU/NtoUsDpAQQchTJto1lCRkWl74Kll8Wt2Ao=; b=FC7A9Tf7nqxxexXZanukfvZTqUy7xRi1+cTSX0n56HshKAL9N5J2fGj0JxBJ7l+5Mk iW/XurFIEWFVR0LllPmCUDYIUAzHl6aZEBPQX2b6/vVJzA2vWJw2DY+rK/QLF4dfVeyx 613q0q11aDRgG+FiukyGN5t25e8TxVH/+bphM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=qXE43rFc3iFY6mHCx7or9wLDqrL4A184mWVqL45IfY/oU5zx19pJy3DyvDr7I3qNSF 3YEEAThKXSHbViiAbAe8ax7kOCFy6i5M6ubWaexG1NhYZle38gkSswKTVwyIcnaZ1Fr7 AWUFEx1DQm31UfUjU+HLQC/RZxrxwlUWmW0aY= Received: by 10.216.90.79 with SMTP id d57mr1093518wef.117.1258418172856; Mon, 16 Nov 2009 16:36:12 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 5sm308822eyf.10.2009.11.16.16.36.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 16:36:12 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B01EFF8.7080909@jacaranda.org> Date: Tue, 17 Nov 2009 00:36:08 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <20091116055101.9D38969F87F@kilo.networkresonance.com> <20091116171246.772ED69F9E5@kilo.networkresonance.com> <4B0199DD.5080904@pobox.com> In-Reply-To: <4B0199DD.5080904@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig26ACD78F6AC4233040576D8D" Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 00:36:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26ACD78F6AC4233040576D8D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Please, can everyone please retain the attribution lines at the top of replies, and preferably also sufficient context to resolve the referents of phrases such as "this problem"?] Michael D'Errico wrote: > [Eric Rescorla wrote:] >> [Martin Rex wrote:] >> >>> ... it is very important that we can signal on ALL future TLS >>> connections established by a client, so that a MITM can not FORCE an >>> updated, but backwards compatible client to renegotiate insecurely >>> with an updated, but backwards compatible server. This is what the >>> TLS extensions RI currently fails completely. >> >> I don't agree with this claim. >> >> A client which sends RI only on renegotiation and aborts the connectio= n >> if it does not receive RI in return does not have this problem. >=20 > You do not appear to fully understand the attack. It is completely=20 > unnecessary for a client to abort a renegotiation. There is no possibl= e > man-in-the-middle. That's not correct. The client should abort such a renegotiation in order to prevent variants of the attack in which the client sees a renegotiation, and the server doesn't. > This is guaranteed when the client has verified the > server's certificate in its initial handshake. Consider the case where client certificates are used, and the server has a "wildcard certificate". Then the attack allows a MITM who can subvert any server matching the wildcard, to prepend data to a session between a client authorized by a client cert, and any other server matching the wildcard. This shouldn't be possible; it's a violation of TLS's designed security properties. If patched clients behave according to Eric's statement above= , then this attack is prevented. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig26ACD78F6AC4233040576D8D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksB8AAACgkQWUc8YzyzqAffAAEAhMukdhekbmGpq7NzCyji3ZQY wSnhV4Bckq7qgiX2G1MBAJH8Sw4tkA/wm0/UeeUbQotwmLDrny0lW3homciRKZ9l =iyko -----END PGP SIGNATURE----- --------------enig26ACD78F6AC4233040576D8D-- From mrex@sap.com Mon Nov 16 16:49:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1DE3A6A53 for ; Mon, 16 Nov 2009 16:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.275, 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 hz49uOMo9Te7 for ; Mon, 16 Nov 2009 16:49:36 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 327C63A6A4F for ; Mon, 16 Nov 2009 16:49:36 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAH0nX2Q004939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 01:49:33 +0100 (MET) From: Martin Rex Message-Id: <200911170049.nAH0nWcH010742@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Tue, 17 Nov 2009 01:49:32 +0100 (MET) In-Reply-To: <4B01A872.1010509@jacaranda.org> from "David-Sarah Hopwood" at Nov 16, 9 07:30:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 00:49:38 -0000 David-Sarah Hopwood wrote: > > Martin Rex wrote: > > Do you realize how much implementation and testing is involved when > > shipping the fix as a TLS extension. > > Yes. Are you suggesting that a fix that uses some other ad hoc signalling > mechanism does not need to undergo thorough interoperability testing? For the ad-hoc signaling a patched browser will be perfectly sufficient for testing. For TLS extensions, you will need to develop yourself a whole test client that is able to generate a certain number of test-scenarios. See here: http://www.ietf.org/mail-archive/web/tls/current/msg04351.html > > > If someone with an old server, who doesn't implement renegotiation and > > TLS extensions wants to add this patch, he will need to add the entire > > TLS extensions handling in a generic fashion and require a significantly > > larger interop testing scenario to make sure that it acutally works: > > If a server doesn't implement renegotiation, then it is already as secure > as it can be with respect to this attack. The server only needs to be > patched so that strict clients will recognize it as patched. > > To achieve that, the server clearly must signal something in a message > that it sends. If that is not done using an extension, then it must be > done using another mechanism such as recognizing a magic ciphersuite and > stuffing its response in some covert channel (which I cannot believe we > are even seriously discussing, frankly). Huh? If the client is signaling that it is updated and will understand whatever the spec says the server should indicate in return, then this is just fine. The spec could even go as far as completely redesigning the ServerHello, completely different from TLS. We could also invent a new handshake message to be sent just after ServerHello, if people prefer this instead of re-purposing an existing element of ServerHello in a well-defined situation. (it would need to be a handshake message, alerts are invisible to the handshake message hash and finished mac). > > Remember, complicated kludges such as fallback to accomodate broken server > implementations are only needed, if they are needed at all, on the client > side. Implementing extensions on the server side is completely trivial. > Many server implementors have already done that work, whereas *no* server > implementors have done the work to support any newly invented signalling > mechanism. I have seriously thought about how to implement my ideas in OpenSSL, and there your assumption about TLS extensions being easier do _not_ apply. > > > You're going to waste network bandwith eternally in a completely > > useless fashion. > > The bandwidth usage is completely insignificant, even for highly constrained > environments. If I've calculated correctly, the size of the extension is > 5 bytes in each direction in the most common, non-renegotiating case > (17 or 29 bytes when renegotiating), and it adds no round-trips. Compare > that to X.509 certificate sizes, which are typically at least 1 KiB each. It is still pure waste, any way you look at it. -Martin From mrex@sap.com Mon Nov 16 17:29:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF983A67E7 for ; Mon, 16 Nov 2009 17:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.264, 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 RGCeDDcjR-AA for ; Mon, 16 Nov 2009 17:29:02 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id F13F53A676A for ; Mon, 16 Nov 2009 17:29:01 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAH1SwAi021125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 02:28:58 +0100 (MET) From: Martin Rex Message-Id: <200911170128.nAH1SwoR013299@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Tue, 17 Nov 2009 02:28:57 +0100 (MET) In-Reply-To: from "Yngve N. Pettersen" at Nov 17, 9 01:14:38 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Suggestions regarding renego extensions, for present, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 01:29:03 -0000 Yngve N. Pettersen wrote: > > > > Why not just change the finished calculation right away for all existing > > protocol versions including SSLv3 and get rid of the TLS extension > > on the renegotiation handshake entirely. That is going to save > > many lines of code, network bandwidth, protcol complexity and > > pages in the TLSv1.3 spec describing this additional complexity. > > > The reason for not just changing the finished calculation in the > background for pre-TLS 1.3 is that clients and servers using TLS 1.2 and > earlier (including SSLv3) must be able to tell, during the *first* > handshake, whether or not the other side is using the safe renegotiation > method, while still being able to complete negotiation with an unpatched > client or server during a transition period. Maybe you're slightly confused by the parallel discussions on the list. *I* want to change only the finished message calculation for the renegotiation handshake, and if you signal through ClientHello and ServerHello, then you can determine with ease after sending the ServerHello (client) or after processing the ServerHello (client) whether a fallback to old-style renegotiation should be permitted (per configuration/app steering) or whether the verify_data of the finished messages from the previous handshake should be added to the handshake message hash. Extending the previously made example for OpenSSL 0.9.8g to include a configuration option for backwards compatibility: Server Side: s3_srvr.c:ssl3_send_server_hello() return(ssl3_do_write(s,SSL3_RT_HANDSHAKE)); would have to be change to something like: ret = ssl3_do_write(s,SSL3_RT_HANDSHAKE); if ( ret>0 && s->s3->renegotiate ) { if ( !s->s3->patched_client_flag ) { if ( 0==(s->options & SSL_OP_ALLOW_INSECURE_RENEGOTIATE) ) { ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_HANDSHAKE_FAILURE); ret = -1; } } else { /* add previous verify_data of client.finished */ ssl3_finish_mac(s,s->s3->peer_finished_md, s->s3->peer_finished_md_len); /* add previous verify_data of server.finished */ ssl3_finish_mac(s,s->s3->finished_md, s->s3->finished_md_len); } } return(ret); > > IMO The best way to accomplish that goal (in pre-TLS 1.3) is by including > the chaining information in the handshake through the handshake messages. > The question is how? My preference is to use the RI extension whenever > possible in pre-TLS 1.3, since it is cleaner protocol-wise, We are NOT adding an optional extension to TLS! In TLSv1.0 (and spec-wise even TLSv1.1) TLS extension is something entirely optional, and we are trying to build a fix for the base protocol that should be as close to mandatory as possible for protocols that we have finalized many years ago. This defect TLS is an exception. I do not expect that we need to fix flaws in the TLS base protocol on a regular basis in the future (at least I strongly hope so). If we want implementors to hotfix this as quickly as possible underneath as many unchanged apps as possible, then why do you have such a significant problem to add it to existing protocols with as little contortions as possible. If we think that adding this to the TLSv1.3 base protocol instead of carrying it around through extensions eternally, then we can just do it right and fix the existing protocols in just the same fashion. It is easier, less code, less explaining, less confusion. It should have been there all the time. How do think people would have fixed this problem when it had been found in 1998 or 2000? By inventing TLS extensions first and then asking everyone to implement it? I really don't think so. Please, put this fix were it belongs, where it should go in TLSv1.3 and where it should have been since 14 years in SSLv3,TLSv1.0,TLSv1.1 and TLSv1.2 -Martin From Chris.Newman@Sun.COM Mon Nov 16 18:17:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D6E3A6877 for ; Mon, 16 Nov 2009 18:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 VR3oNkUN3lSD for ; Mon, 16 Nov 2009 18:17:06 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id B70AD3A67FC for ; Mon, 16 Nov 2009 18:16:36 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAH2GZiO020377 for ; Mon, 16 Nov 2009 18:16:35 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT800100E336Q00@fe-sfbay-09.sun.com> for tls@ietf.org; Mon, 16 Nov 2009 18:16:35 -0800 (PST) Received: from vpn-129-150-241-98.sfbay.sun.com ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT800LVFEBL0A10@fe-sfbay-09.sun.com>; Mon, 16 Nov 2009 18:16:35 -0800 (PST) Date: Mon, 16 Nov 2009 18:16:32 -0800 From: Chris Newman In-reply-to: Sender: Chris.Newman@Sun.COM To: Bodo Moeller , Nelson B Bolyard Message-id: <3B58B7A4C88EA8CA7C30C4E7@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> <4B006D46.6070107@bolyard.me> Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 02:17:07 -0000 --On November 15, 2009 13:48:28 -0800 Bodo Moeller wrote: > - the attack is irrelevant for opportunistic-encryption scenarios -- I disagree with this assertion. Opportunistic TLS for SMTP-relay is highly problematic. I would recommend sites disable STARTTLS for SMTP relay on port 25 until they patch their TLS stacks. I would keep STARTTLS enabled for SMTP submission (RFC 4409, where a server is configured to require SMTP AUTH for all submissions). In the email standards world, we have been promoting the idea that SMTP submission (RFC 4409) and relay (RFC 5321) need to be treated as independent services with independent configuration (RFC 5068). This is yet another case where we were correct. - Chris From Chris.Newman@Sun.COM Mon Nov 16 19:23:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C123A6A44 for ; Mon, 16 Nov 2009 19:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 977FRh-8qKx9 for ; Mon, 16 Nov 2009 19:23:40 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id B77C43A6A26 for ; Mon, 16 Nov 2009 19:23:40 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAH3Ndsa006410 for ; Mon, 16 Nov 2009 19:23:39 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT800000H3NGI00@fe-sfbay-10.sun.com> for tls@ietf.org; Mon, 16 Nov 2009 19:23:39 -0800 (PST) Received: from vpn-129-150-241-98.sfbay.sun.com ([unknown] [10.1.110.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT800MAZHFD0M20@fe-sfbay-10.sun.com> for tls@ietf.org; Mon, 16 Nov 2009 19:23:39 -0800 (PST) Date: Mon, 16 Nov 2009 19:23:37 -0800 From: Chris Newman Sender: Chris.Newman@Sun.COM To: tls@ietf.org Message-id: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: [TLS] user requirements for TLS fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 03:23:41 -0000 As a power user, I want two settings for my all my TLS clients ASAP: 1. treat unpatched servers as if SSL/TLS was not being used with respect to security indicators in the UI; but otherwise continue with connection. 2. Warn when contacting an unpatched server giving me the option to abort the transaction (and even better if it won't bother me for a month or so if I choose to continue). I will use option 1 most of the time initially and will switch to option 2 when the time is right (maybe a year or so?). A non-power user is best served by option 1 for the foreseeable future, but this will generate support calls that some ISPs and business enclaves will find unacceptable. These sites will insist on a "no change from today" behavior until the majority of servers are patched or enough customers/banks demand otherwise. Closed-source client vendors are likely to make options 1 & 2 default off for that reason. Open-source clients might get away with option 1 default on. Particularly security sensitive sites will want the ability to log on the server and/or block at the outbound firewall clients that are not patched. Such sites will also require that un-patched clients work with internal already-patched servers for a transition period. I would consider option 1 suitable for an IETF best _current_ practice document. That would mean we expect most clients to send the RI extension most of the time, even if they have no plans to renegotiate later, as that's they only way the client can produce a correct security indicator for the user. This will have issues with previously mentioned (but as yet unidentified) broken SSL 3 server implementations. It is possible to produce an alternative proposal with a slightly better backwards compatibility profile than draft-rescorla-tls-renegotiation-00 that meets the above user requirements. However, there is no such proposal in the form of an Internet draft that has been both implemented and interoperability tested between implementations to the level that RI has. I consider time-to-market a much higher priority than backwards compatibility with servers that implemented SSL 3 incorrectly. So at this stage I propose we immediately adopt draft-rescorla-tls-renegotiation-00 as a WG document (I understand this decision is the chair's discretion), get it revised to fix the issue Nelson identified and start IETF last call and WG last call in parallel. - Chris From mike-list@pobox.com Mon Nov 16 19:47:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3033A685A for ; Mon, 16 Nov 2009 19:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 i4x84+FUtPcj for ; Mon, 16 Nov 2009 19:47:13 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id DEC153A6823 for ; Mon, 16 Nov 2009 19:47:12 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7E2189E9A5 for ; Mon, 16 Nov 2009 22:47:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=ZFIXIM4rS//m k0VQOkrUslNwpcc=; b=RwAv61bONymHoECP7EwXp0ek38IkpKO40nqhhV6FZeef 4Kzt6/vgcSQ6e8fg5DCsp0S/EXajRlJ28mQ3z102+/HKP3Pb5YmEOkh5LfZl5Lkr y89VOhKhty6TW6glFgftxp8YdZ3tLKsS+y93vJrGeIzluI+lbiLu/ChYcRsYKVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=AH5C4P GJxiGwz3XSN6ez04EYBjRpxiBmOZTE9iAEWkO0rm78zHCHBmKH7YFj75AD0XPjt5 XVeW2/ZQTsMJnz1XPL14hagmYRRzy2WUVkebC8VE+rDUt70PUqavl+pSqKSGDBRN qJe6mbdjIC5lPaizOKQT8175wAlpO3ZTSo4v0= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7BFEA9E9A4 for ; Mon, 16 Nov 2009 22:47:11 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 0D7049E9A3 for ; Mon, 16 Nov 2009 22:47:10 -0500 (EST) Message-ID: <4B021CFF.4080801@pobox.com> Date: Mon, 16 Nov 2009 19:48:15 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> In-Reply-To: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E3163218-D32B-11DE-B824-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] user requirements for TLS fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 03:47:13 -0000 I appreciate wanting to move on this, but the heated discussion over the past few days has been over problems with the RI extension. The good news is that I think we've finally reached consensus on a better alternative. I summarized it in another message, with a slight twist that makes it even more compatible with existing code since no extensions are required in either direction. Please see: http://www.ietf.org/mail-archive/web/tls/current/msg04393.html I've already implemented the RI extension in my own code, so it will be extra work for me to rip out my changes and start anew, but I do believe this is better for the rest of the world that still has yet to implement a fix. Mike Chris Newman wrote: > As a power user, I want two settings for my all my TLS clients ASAP: > > 1. treat unpatched servers as if SSL/TLS was not being used with respect to > security indicators in the UI; but otherwise continue with connection. > > 2. Warn when contacting an unpatched server giving me the option to > abort the transaction > (and even better if it won't bother me for a month or so if I choose > to continue). > > I will use option 1 most of the time initially and will switch to option > 2 when the time is right (maybe a year or so?). > > A non-power user is best served by option 1 for the foreseeable future, > but this will generate support calls that some ISPs and business > enclaves will find unacceptable. These sites will insist on a "no > change from today" behavior until the majority of servers are patched or > enough customers/banks demand otherwise. Closed-source client vendors > are likely to make options 1 & 2 default off for that reason. > Open-source clients might get away with option 1 default on. > > Particularly security sensitive sites will want the ability to log on > the server and/or block at the outbound firewall clients that are not > patched. Such sites will also require that un-patched clients work with > internal already-patched servers for a transition period. > > > I would consider option 1 suitable for an IETF best _current_ practice > document. That would mean we expect most clients to send the RI > extension most of the time, even if they have no plans to renegotiate > later, as that's they only way the client can produce a correct security > indicator for the user. This will have issues with previously mentioned > (but as yet unidentified) broken SSL 3 server implementations. > > It is possible to produce an alternative proposal with a slightly better > backwards compatibility profile than draft-rescorla-tls-renegotiation-00 > that meets the above user requirements. However, there is no such > proposal in the form of an Internet draft that has been both implemented > and interoperability tested between implementations to the level that RI > has. I consider time-to-market a much higher priority than backwards > compatibility with servers that implemented SSL 3 incorrectly. So at > this stage I propose we immediately adopt > draft-rescorla-tls-renegotiation-00 as a WG document (I understand this > decision is the chair's discretion), get it revised to fix the issue > Nelson identified and start IETF last call and WG last call in parallel. > > - Chris From Chris.Newman@Sun.COM Mon Nov 16 20:05:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D982B3A6838 for ; Mon, 16 Nov 2009 20:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 1qig5cZUKRpM for ; Mon, 16 Nov 2009 20:05:33 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 38AF33A68FA for ; Mon, 16 Nov 2009 20:05:33 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAH45Wdg024644 for ; Mon, 16 Nov 2009 20:05:32 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT800J00J7DGS00@fe-sfbay-10.sun.com> for tls@ietf.org; Mon, 16 Nov 2009 20:05:32 -0800 (PST) Received: from vpn-129-150-241-98.sfbay.sun.com ([unknown] [10.1.110.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT800MOOJD50M20@fe-sfbay-10.sun.com>; Mon, 16 Nov 2009 20:05:31 -0800 (PST) Date: Mon, 16 Nov 2009 20:05:29 -0800 From: Chris Newman In-reply-to: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> Sender: Chris.Newman@Sun.COM To: mrex@sap.com Message-id: <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 04:05:33 -0000 --On November 16, 2009 18:25:32 +0100 Martin Rex wrote: > But when a proposal enters the IETF process, the IETF and the > working group should discuss it based on its technical merits. The IETF is about rough consensus and running code. Technical merit is one aspect of that. Time to market can be important. Technical maturity of the specification can be important. The best or perfect proposal often takes longer to develop than the good enough proposal and thus loses. Just look at how badly HTTP is designed when it comes to authentication -- but it was good enough to standardize. The HTTP Next-Generation working group failed because HTTP is good enough. draft-rescorla-tls-renegotiation-00 already has lots of running code; and that's a traditional IETF litmus test that correctly makes alternative proposals far less attractive. If you want your alternative proposal to be considered, submit an Internet draft and get some running code and feedback from implementations showing your proposal would deploy protection to more users than draft-rescorla-tls-renegotiation-00. Then you may sway people to your viewpoint. But time-to-market is __very__ important for this particular problem. I think you have already spent too much time arguing on the list and not enough time writing specs and gathering implementation experience to make a viable alternative proposal. - Chris From nelson@bolyard.me Mon Nov 16 20:37:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711CB3A68A5 for ; Mon, 16 Nov 2009 20:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 SJ8knNNKNd8j for ; Mon, 16 Nov 2009 20:37:23 -0800 (PST) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id 4692D3A67E2 for ; Mon, 16 Nov 2009 20:37:20 -0800 (PST) Received: (qmail 7170 invoked from network); 17 Nov 2009 04:37:18 -0000 Received: from unknown (24.5.142.42) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 17 Nov 2009 04:37:18 -0000 Message-ID: <4B022826.5080701@bolyard.me> Date: Mon, 16 Nov 2009 20:35:50 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> In-Reply-To: <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 04:37:24 -0000 On 2009-11-16 20:05 PST, Chris Newman wrote: > draft-rescorla-tls-renegotiation-00 already has lots of running code; and > that's a traditional IETF litmus test that correctly makes alternative > proposals far less attractive. Could we get a show of hands for working implementations of that draft? - I have one in NSS (used in Mozilla clients and Sun servers). - Michael D'Errico has one. I've successfully i18y tested with it. - Microsoft has one. I've done very limited I18y testing with it. - OpenSSL has one, IINM. (Haven't done a test with it yet) - RSA claims to have one, IINM. (Haven't tried it yet, Either.) Are there others? > But time-to-market is __very__ important for this particular problem. I agree. From mike-list@pobox.com Mon Nov 16 21:02:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932CA3A689C for ; Mon, 16 Nov 2009 21:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.172, 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 jt5SU7D8F4Kr for ; Mon, 16 Nov 2009 21:02:53 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 9F5423A63C9 for ; Mon, 16 Nov 2009 21:02:53 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id F198D809B6 for ; Tue, 17 Nov 2009 00:02:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=3Yzlh5c/WqXa nsTYpLPfVZmnM30=; b=mQ47LZYtpTGWKxo2bCDmfG9U1fOLdbqzHtdGD2aKMeC5 7KTXcOPNZhtUTbLJ7c2hSgccDoTQ4kbLRRog8XU60bcXiLyEzzrVKF2xINqdRsMd 8N81rw3G6BJUVpBkI558vHfg2btMdswOIvOrTkes4hnMCYKZBa6tEu2n+awA8lY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=IAdAUA DEvVwRjDcxzKBFLkTYJg9KnCNsxq2B8CVslL6+JzCTD3MXSA9XzEKw3RznHWJWvD NcJFKj/iFSSCg/2m38vhxdx/HzeBCbkyjfEA2M0c7fmJWxP3/wKLKl2vdY0n7tKb wLjgGnGrIWjbXifWxCqVgJXNff1fbUm7ZTSVY= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EDADF809B5 for ; Tue, 17 Nov 2009 00:02:50 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 7B664809B4 for ; Tue, 17 Nov 2009 00:02:50 -0500 (EST) Message-ID: <4B022EBB.5030108@pobox.com> Date: Mon, 16 Nov 2009 21:03:55 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> In-Reply-To: <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 74D26F3C-D336-11DE-A5BA-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 05:02:54 -0000 > If you want your alternative proposal to be considered, submit an > Internet draft and get some running code and feedback from > implementations showing your proposal would deploy protection to more > users than draft-rescorla-tls-renegotiation-00. Then you may sway > people to your viewpoint. Here is how draft-rescorla-tls-renegotiation-00 fails to protect the most people: - there are so many interoperability problems with TLS extensions that even the author of the draft suggests that a "lenient"[*] client not send the extension on its initial connection - there will be a transition period where some servers absolutely need to continue allowing unpatched clients to perform the current vulnerable renegotiation. - a lenient client's handshake without the RI extension looks just like an unpatched client that these unfortunate servers need to continue supporting - a man-in-the-middle can take advantage of these three points to victimize a patched client talking to a patched server! Just today many of us have converged on an alternate solution that does not have this serious problem. Instead of using extensions with all the myriad problems, the only bits-on-the-wire change is to include a single special cipher suite that signals to the server that the client wishes to use a new calculation of the Finished messages that includes the verify_data from the previous handshake. I suggested that an alert message could be used for the server to acknowledge back to the client. This uses only features that are present in SSLv3, so it is much more likely to be implemented quickly and correctly, and it does not require implementations to add any code for extension processing if they don't already support extensions. It also protects the lenient client and unfortunate servers above since there is no reason not to include the magic cipher suite in ALL handshakes. Here is a pointer to a summary of the proposal: http://www.ietf.org/mail-archive/web/tls/current/msg04393.html I am not a spec. writer, so someone else should write it up. If it is adopted I will implement it in my test server in short order for anyone to test against. Mike [*] a lenient client is one that would connect to any server regardless of whether it is patched or not. Since there is a not-insignificant chance that a server will barf on the use of extensions, and the lenient client wouldn't abort the handshake even if the extension is not returned by the server, it is less painful to just do what's always been done. From djhopwood@googlemail.com Mon Nov 16 21:14:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80ADE3A68B4 for ; Mon, 16 Nov 2009 21:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 lESIC3T+U7Kq for ; Mon, 16 Nov 2009 21:14:04 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id E3EC13A6858 for ; Mon, 16 Nov 2009 21:14:03 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so2203648eyd.51 for ; Mon, 16 Nov 2009 21:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Q4giVElHYc9HzqFnAtYiJ2DOjquMg7RONbO1VuRsI/Q=; b=cPUWCb7/eXzseZQKUeq8WWMQCoURK174gx/fvRkWSg1w6uxxB0+WNXoLHCN3TTXjBI AtzSLKcDqTDJ/Cvl/uiF+Rs9IlEKbI91tJAULIgwWtmRNASIYOycFFyhaqBmFZmzfRZ1 7y/Ds/ALs7lbD+pSLcRXqNn3J4VkmwlngfolQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=foAdf8l1Jnd+TnRXptopuCEUgQIVzXX0guCMY0iVH27Chy/kPYoxeuoRSkeE1y9doX IYlYQcT2ks7j7SesgoQSNZGQfte1LrAZ6itce4CBLP2U4WjLLw7gzYDfFUpQHQsDIi5v CvwN/qDne7OQa+OWFgiDGitPCCN8qplp7uk5Q= Received: by 10.213.102.138 with SMTP id g10mr932954ebo.76.1258434836635; Mon, 16 Nov 2009 21:13:56 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 28sm168431eye.5.2009.11.16.21.13.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 21:13:56 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B023101.9030005@jacaranda.org> Date: Tue, 17 Nov 2009 05:13:37 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> <4B021CFF.4080801@pobox.com> In-Reply-To: <4B021CFF.4080801@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB88562700014C076D81565CB" Subject: Re: [TLS] user requirements for TLS fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 05:14:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB88562700014C076D81565CB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > I appreciate wanting to move on this, but the heated discussion over > the past few days has been over problems with the RI extension. The > good news is that I think we've finally reached consensus on a better > alternative. I summarized it in another message, with a slight twist > that makes it even more compatible with existing code since no > extensions are required in either direction. >=20 > Please see: >=20 > http://www.ietf.org/mail-archive/web/tls/current/msg04393.html That article has currently had no replies. How can you say that the group has reached concensus, on that solution or any other? It very clearly hasn't. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB88562700014C076D81565CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksCMQ8ACgkQWUc8YzyzqAcPdwEAnntPVrtoJBdC722/zVf7sJGg GU9tV4A0JDXpKSKmyxQA/2w1WOlKv0PCWerxVnSYxVA16OCV8RsI8fCf8m8UDGnW =M0qW -----END PGP SIGNATURE----- --------------enigB88562700014C076D81565CB-- From mike-list@pobox.com Mon Nov 16 21:15:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55E13A694C for ; Mon, 16 Nov 2009 21:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 VcCyZiRs6B5g for ; Mon, 16 Nov 2009 21:15:18 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 1273E3A68F9 for ; Mon, 16 Nov 2009 21:15:18 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1F50E80ACF for ; Tue, 17 Nov 2009 00:15:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=i//jn7WynCqR 52wZcddFMPEhmqQ=; b=X78KLrMNKpM8iFRo5VC397Qmjw9/h6ngdq+limQrSb6m /W3yFQaIZF9V18IWeWONmATIFk9jBx4nfOAyG7fU7Oko+23RS6voc4hldnAkNZNt +lhDpCEW6azfwDOMyXK9dHUwQIRm0GQbumU2LzsxTxFomYNCG8Zv5mo3VPavon0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=MLN8aS PTn4Qy9moF1tBLF38XBHnJurhZmLBeCD17MDPX8gUGLQ1+Va0tyaUvAFDdga5hR/ 2qwlbUZA1nteh6lC4hEr2TGOn82CFOMEvIrsD6o9cg9+EYWdCTnxFsWuoheIon8b 6AM3kmyej4EKSLlLcuGlZGqrnf8r0X6d+zAtU= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1C1A080ACE for ; Tue, 17 Nov 2009 00:15:17 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C70DD80ACD for ; Tue, 17 Nov 2009 00:15:16 -0500 (EST) Message-ID: <4B0231A6.4090005@pobox.com> Date: Mon, 16 Nov 2009 21:16:22 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022826.5080701@bolyard.me> In-Reply-To: <4B022826.5080701@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 318F57EC-D338-11DE-8697-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 05:15:18 -0000 >> But time-to-market is __very__ important for this particular problem. > > I agree. Time is important, absolutely. But the important measure of time is not how fast we publish a spec. It is how quickly that spec. is implemented by the rest of the world! If extensions are required in our published spec, there will be a hurdle for some that is entirely unnecessary. The responsible thing for us is to use features available in the SSLv3 spec. I have summarized a proposal that contains ideas from many people on this list which uses only SSLv3-compatible features: http://www.ietf.org/mail-archive/web/tls/current/msg04393.html I can implement this very quickly, and it will be less code than what it took to implement the current draft (even though I already supported extensions). Mike From mike-list@pobox.com Mon Nov 16 21:25:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB2F3A6A36 for ; Mon, 16 Nov 2009 21:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 iOMZ+0CZLTNj for ; Mon, 16 Nov 2009 21:25:39 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id D5F413A68ED for ; Mon, 16 Nov 2009 21:25:39 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 93C3880B6A for ; Tue, 17 Nov 2009 00:25:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=pmivG7wFIgZt R9ZXU7mR99cpjow=; b=uXFWkbQp5gXSdBCuyEKTzX24yyPZjUYXtIggZEHIxmKb 2GvEzvypcGOgzIdVz7XHXck26bHonNNgkYtCb1pRHGcJjv6QF0w/V98AZRlzJEMo OxNF0cJk/RPkpkoUp8vVsImprrPP6SOX3iYANc461TJZAq4LhtXIKeV6UprWCw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=yIDAkN Yt8UisOQnuufnh4rmsgtyapHkSiBoUbe3z1Xvi+RgcXsMYhBCZ5wA2PRpqWiQX+0 fifi8n3iSkbABEyI/B89u2pX6VfjRldJQt+GwQXgWmGDx0brhkwcccqvKMQjpwKc k/21II+uyo1J9RIpdjGdciFsiGJX9wpFMIAIE= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 904D780B69 for ; Tue, 17 Nov 2009 00:25:38 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 48BBA80B68 for ; Tue, 17 Nov 2009 00:25:38 -0500 (EST) Message-ID: <4B023413.1070105@pobox.com> Date: Mon, 16 Nov 2009 21:26:43 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> <4B021CFF.4080801@pobox.com> <4B023101.9030005@jacaranda.org> In-Reply-To: <4B023101.9030005@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: A3FE0656-D339-11DE-A4F9-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] user requirements for TLS fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 05:25:40 -0000 "Consensus" was clearly the wrong word. "Convergence" would have been more appropriate. I've read every word of every message and it's clear that this has all the ingredients people are asking for: - is minimally invasive: works even for SSLv3 without needing extensions or modifying any handshake message in any way - signals in both directions in the clear - incorporates the previous verify_data in the handshake - does not waste bandwidth - protects "lenient" clients as much as possible - probably others Since you read it, care to comment? Mike David-Sarah Hopwood wrote: > Michael D'Errico wrote: >> I appreciate wanting to move on this, but the heated discussion over >> the past few days has been over problems with the RI extension. The >> good news is that I think we've finally reached consensus on a better >> alternative. I summarized it in another message, with a slight twist >> that makes it even more compatible with existing code since no >> extensions are required in either direction. >> >> Please see: >> >> http://www.ietf.org/mail-archive/web/tls/current/msg04393.html > > That article has currently had no replies. How can you say that the > group has reached concensus, on that solution or any other? It very > clearly hasn't. From peter.robinson@rsa.com Mon Nov 16 23:20:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94083A68F2 for ; Mon, 16 Nov 2009 23:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, 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 2Pb8QbD01CO7 for ; Mon, 16 Nov 2009 23:20:05 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 662873A6870 for ; Mon, 16 Nov 2009 23:20:05 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nAH7K1AK021466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 02:20:01 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 17 Nov 2009 02:19:52 -0500 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id nAH7Jp2c014327; Tue, 17 Nov 2009 02:19:51 -0500 Received: from CORPUSMX100B.corp.emc.com ([128.222.76.52]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 02:19:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Nov 2009 02:19:51 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0F03_01CA67AA.2BD5E5E0" Message-ID: In-Reply-To: <4B022826.5080701@bolyard.me> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpnP6y1B+qBTVnwRnK3I72ZwoIk3wAFYgkg References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp><089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022826.5080701@bolyard.me> From: To: , X-OriginalArrivalTime: 17 Nov 2009 07:19:51.0445 (UTC) FILETIME=[5A5E2C50:01CA6756] X-EMM-EM: Active Cc: david.makepeace@rsa.com, sean.parkinson@rsa.com, kathy.kriese@rsa.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 07:20:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0F03_01CA67AA.2BD5E5E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >Could we get a show of hands for working implementations of that draft? > >- I have one in NSS (used in Mozilla clients and Sun servers). >- Michael D'Errico has one. I've successfully i18y tested with it. >- Microsoft has one. I've done very limited I18y testing with it. >- OpenSSL has one, IINM. (Haven't done a test with it yet) >- RSA claims to have one, IINM. (Haven't tried it yet, Either.) Pre-release versions of the following products support the extension: RSA BSAFE(R) SSL-J, RSA BSAFE(R) Share for JavaTM Platform, RSA BSAFE(R) MES, RSA BSAFE(R) Share for C/C++. RSA BSAFE(R) SSL-C and RSA BSAFE(R) SSL-C ME will follow in the coming weeks. If anyone would like to test interoperability with our products please send me an email. As per my earlier post: RSA, The Security Division of EMC, has created a TLS Interoperability Server to allow inter-op testing of TLS. The static content of the server is here http://203.166.62.199/ Please email me the following information so I can have your IP address added to a white list so you can access the inter-op servers themselves. * Contact Information Name Organization or Company name and Business Unit Address Phone Number Email address * IP Address(es) which you will be connecting from. * Product(s) and version(s) you will be testing. * TLS protocol versions, cipher suites and curves you wish to test. ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. ------=_NextPart_000_0F03_01CA67AA.2BD5E5E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWmzCCAucw ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1 s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5 IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3 Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/ eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5 /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1 cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13 qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggR+MIID56ADAgECAhEAsSe9 yNTH2rYKRiN7F8KhkTANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT MB4XDTA5MDcyMTA1MTYxM1oXDTExMDcyMjA1MTYxM1owgekxEzARBgoJkiaJk/IsZAEZFgNjb20x EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjEMMAoGA1UECxMD UlNBMRUwEwYDVQQLEwxBc2lhL1BhY2lmaWMxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQF EwYwNjQ4MTQxFzAVBgoJkiaJk/IsZAEBEwdyb2JpbnAyMRcwFQYDVQQDEw5QZXRlciBSb2JpbnNv bjElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA2CcjIV2QNoJP4YbPejhZX2MSu53/EooTnrkf7M4gsl1DobXkk3CO6kU9bN6O wwL/o87dQ4y2FHjwkV4WeoodhvZa08q5uX4vZCtB2Hn0OUrbPzyKl7wXSq+yezKCQJBrVCTwWjKK A6Gqc1VhkqWSBCpUaQ39TsVDxNYCGIn433cCAwEAAaOCAX8wggF7MIGSBgNVHSAEgYowgYcwgYQG CSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5o dG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9y YXRlZCBieSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnBldGVyLnJvYmluc29uQHJzYS5jb20wDgYDVR0PAQH/BAQDAgeAMEYG A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQm 7p962rS9dUpGeQZt+Vi1su6tQTANBgkqhkiG9w0BAQUFAAOBgQCghPP5wxcDJuACPYJ/U1sjhyE4 gxpGKZNPnnDcjfHo+Cq87cWawpV5Rzpg8KVZc0EoG6BabGNyk+WgZMjCzADpg+appN4cX+DML0ir 3cBcX8pQTuKw1VRlUjidjkTIl/Z2hrcvgh2lJG+PFV2ogWICzwOj4/zKG4khs9VO5NNPezCCBI4w ggP3oAMCAQICEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFS U0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xh c3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czELMAkGA1UEBhMCVVMwHhcNMDkwNzIxMDUxNjE4WhcNMTEwNzIyMDUxMzM2WjCB7TETMBEGCgmS JomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0 aW9uMQwwCgYDVQQLEwNSU0ExFTATBgNVBAsTDEFzaWEvUGFjaWZpYzEUMBIGA1UECxMLRW5naW5l ZXJpbmcxDzANBgNVBAUTBjA2NDgxNDEXMBUGCgmSJomT8ixkAQETB3JvYmlucDIxGzAZBgNVBAMT ElBldGVyIFJvYmluc29uLUVuYzElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqeM4888BmvaveugOJqTYWGNm3cTP6qJe444S 7AJaXDnKZlt1cJByB+B83hdGGe2FyRQGGef0DNZhQIfaa41dzZbDWuogZ3mKxyuOhciZSoRoCIM0 jlPh5vqhDmXBPFQ/EedNPRk+tl+mKVz2fHbsI01bWtueV05BvJu330cj0WUCAwEAAaOCAYswggGH MDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDCB kgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwUwdzAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNl Y3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMC AQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCEGA1UdEQQaMBiBFnBldGVyLnJvYmlu c29uQHJzYS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206 ODAvUlNBQ2xhc3MyUGVyc29uYWxDQS5jcmwwHwYDVR0jBBgwFoAUxpPuxqX+41WOz4ojH+6Y3iHy n6cwHQYDVR0OBBYEFGg/pAQlQSo2dvZeyryhS2toL395MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG 9w0BAQUFAAOBgQCY/nGMkd29x8wULeVsTP+emR/XVn+LqcfwzgwpUSKP1FX1WedrHwlNKFaVDjQX FaNETkV4XzMugf4iafsgZUp5DmzIOBB5H5MI1k+CprZ0tjet7gcN0sdCt0fggfw44GZ37rwxzwyt XZrbEePtb8wFYVEobKBD/ZqvghavL93K3DGCA4EwggN9AgEBMIGiMIGMMRowGAYDVQQKExFSU0Eg U2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3Mg MiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEL MAkGA1UEBhMCVVMCEQCxJ73I1MfatgpGI3sXwqGRMAkGBSsOAwIaBQCgggI0MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExNzA3MTk1MVowIwYJKoZIhvcNAQkE MRYEFLrMu4pWyivONuMB6f95H+bGQtXvMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA PhSJXiBTEl+/eFN69FlLjW2x2UwprCpJepysvI9BnPZEVa7caZugLmsMmsMrs0IDy10p3Aa2UcpM gKPMaNovMpED1f/g86QBKmg+mOK//jRJ8qCOM2IxMXtX1ITv91U6f8ZegbRLWnfQVHhdEPWMP9L8 SvQEvkheW8pV/I8tUMUAAAAAAAA= ------=_NextPart_000_0F03_01CA67AA.2BD5E5E0-- From simon@josefsson.org Tue Nov 17 01:36:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F9D28C13E for ; Tue, 17 Nov 2009 01:36:21 -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 5L6DE9sceGRU for ; Tue, 17 Nov 2009 01:36:20 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 5B63728C0F0 for ; Tue, 17 Nov 2009 01:36:20 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAH9Zt67001712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Nov 2009 10:35:57 +0100 From: Simon Josefsson To: Chris Newman References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> <4B006D46.6070107@bolyard.me> <3B58B7A4C88EA8CA7C30C4E7@446E7922C82D299DB29D899F> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091117:nelson@bolyard.me::wzmdl926JrOg06Uw:YYx X-Hashcash: 1:22:091117:chris.newman@sun.com::1k99KidrlSedJXKY:FIaz X-Hashcash: 1:22:091117:tls@ietf.org::BUDPsLOELWS5YBtv:HP1w X-Hashcash: 1:22:091117:bmoeller@acm.org::NJW+bFcQYu6SvCCc:OvYq Date: Tue, 17 Nov 2009 10:35:55 +0100 In-Reply-To: <3B58B7A4C88EA8CA7C30C4E7@446E7922C82D299DB29D899F> (Chris Newman's message of "Mon, 16 Nov 2009 18:16:32 -0800") Message-ID: <874oot3344.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:36:21 -0000 Chris Newman writes: > --On November 15, 2009 13:48:28 -0800 Bodo Moeller wrote: >> - the attack is irrelevant for opportunistic-encryption scenarios -- > > I disagree with this assertion. Opportunistic TLS for SMTP-relay is > highly problematic. I would recommend sites disable STARTTLS for SMTP > relay on port 25 until they patch their TLS stacks. How does the TLS reneg attack work for SMTP? I haven't seen it explained anywhere, and I don't easily see how it applies. I don't think it is wise to recommend disabling TLS without explaining why. Btw, it is also not clear that the TLS reneg bug even applies to all TLS stacks -- for example GnuTLS requires assistance from the application to do renegotiation, and most applications do not provide that assistance with the result that TLS reneg cannot succeed. So these client/servers using GnuTLS are not vulnerable to the TLS reneg problem. /Simon From yngve@opera.com Tue Nov 17 02:39:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875D728C229 for ; Tue, 17 Nov 2009 02:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 U5aTH3olvHR6 for ; Tue, 17 Nov 2009 02:39:26 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 6D6FD28C22D for ; Tue, 17 Nov 2009 02:39:26 -0800 (PST) Received: from acorna.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAHAc1cl001129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 10:38:04 GMT Date: Tue, 17 Nov 2009 11:39:11 +0100 To: "Nelson B Bolyard" , tls@ietf.org From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022826.5080701@bolyard.me> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4B022826.5080701@bolyard.me> User-Agent: Opera Mail/9.65 (Win32) Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:39:27 -0000 On Tue, 17 Nov 2009 05:35:50 +0100, Nelson B Bolyard wrote: > On 2009-11-16 20:05 PST, Chris Newman wrote: > >> draft-rescorla-tls-renegotiation-00 already has lots of running code; >> and >> that's a traditional IETF litmus test that correctly makes alternative >> proposals far less attractive. > > Could we get a show of hands for working implementations of that draft? > > - I have one in NSS (used in Mozilla clients and Sun servers). > - Michael D'Errico has one. I've successfully i18y tested with it. > - Microsoft has one. I've done very limited I18y testing with it. > - OpenSSL has one, IINM. (Haven't done a test with it yet) > - RSA claims to have one, IINM. (Haven't tried it yet, Either.) > > Are there others? Opera have an implementation, which is currently being polished with warning and error messages, and a kill-switch. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From stephen.farrell@cs.tcd.ie Tue Nov 17 05:09:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D1328C13D for ; Tue, 17 Nov 2009 05:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JaHTgn+lihW for ; Tue, 17 Nov 2009 05:09:29 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id E3A9028C13C for ; Tue, 17 Nov 2009 05:09:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id DF33A1003EB5E; Tue, 17 Nov 2009 13:09:25 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRd47AGaxh7v; Tue, 17 Nov 2009 13:09:25 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 8DE911003EB4D; Tue, 17 Nov 2009 13:09:25 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 819B47C12C; Tue, 17 Nov 2009 13:09:25 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3wshziEylSt; Tue, 17 Nov 2009 13:09:24 +0000 (GMT) Received: from [192.168.3.55] (unknown [192.168.3.55]) by mail01.newbay.com (Postfix) with ESMTP id BFF147C127; Tue, 17 Nov 2009 13:09:24 +0000 (GMT) Message-ID: <4B02A084.9030903@cs.tcd.ie> Date: Tue, 17 Nov 2009 13:09:24 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Chris Newman References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> In-Reply-To: <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 13:09:29 -0000 Chris Newman wrote: > --On November 16, 2009 18:25:32 +0100 Martin Rex wrote: >> But when a proposal enters the IETF process, the IETF and the >> working group should discuss it based on its technical merits. > > The IETF is about rough consensus and running code. Technical merit is > one aspect of that. Time to market can be important. Technical > maturity of the specification can be important. The best or perfect > proposal often takes longer to develop than the good enough proposal and > thus loses. Just look at how badly HTTP is designed when it comes to > authentication -- but it was good enough to standardize. The HTTP > Next-Generation working group failed because HTTP is good enough. > > draft-rescorla-tls-renegotiation-00 already has lots of running code; > and that's a traditional IETF litmus test that correctly makes > alternative proposals far less attractive. Having watched the recent list traffic I find the above convincing. I'd love to see a -01 of the above containing the changes EKR has mentioned already, and then a WGLC on that. S. From mrex@sap.com Tue Nov 17 06:06:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CCF28C15B for ; Tue, 17 Nov 2009 06:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.254, 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 cryGYSMUuLdd for ; Tue, 17 Nov 2009 06:06:18 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 23B5B28C152 for ; Tue, 17 Nov 2009 06:06:17 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAHE6FiR017175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 15:06:15 +0100 (MET) From: Martin Rex Message-Id: <200911171406.nAHE6C1s027660@fs4113.wdf.sap.corp> To: Chris.Newman@Sun.COM (Chris Newman) Date: Tue, 17 Nov 2009 15:06:12 +0100 (MET) In-Reply-To: <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> from "Chris Newman" at Nov 16, 9 08:05:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 14:06:19 -0000 OK. I'm going to write an I-D. I've not done this before -- it'll take me at least one day. In my previous IETF participation, document authors were always quite open minded to improvements, so I never had to actually write a counterproposal. -Martin Chris Newman wrote: > > --On November 16, 2009 18:25:32 +0100 Martin Rex wrote: > > But when a proposal enters the IETF process, the IETF and the > > working group should discuss it based on its technical merits. > > The IETF is about rough consensus and running code. Technical merit is one > aspect of that. Time to market can be important. Technical maturity of > the specification can be important. The best or perfect proposal often > takes longer to develop than the good enough proposal and thus loses. Just > look at how badly HTTP is designed when it comes to authentication -- but > it was good enough to standardize. The HTTP Next-Generation working group > failed because HTTP is good enough. > > draft-rescorla-tls-renegotiation-00 already has lots of running code; and > that's a traditional IETF litmus test that correctly makes alternative > proposals far less attractive. > > If you want your alternative proposal to be considered, submit an Internet > draft and get some running code and feedback from implementations showing > your proposal would deploy protection to more users than > draft-rescorla-tls-renegotiation-00. Then you may sway people to your > viewpoint. > > But time-to-market is __very__ important for this particular problem. I > think you have already spent too much time arguing on the list and not > enough time writing specs and gathering implementation experience to make a > viable alternative proposal. > > - Chris > > From mike-list@pobox.com Tue Nov 17 08:24:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C243A6767 for ; Tue, 17 Nov 2009 08:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 mhMJ6Ggh5KCD for ; Tue, 17 Nov 2009 08:24:31 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 735833A6774 for ; Tue, 17 Nov 2009 08:24:31 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id CE2D09FB69 for ; Tue, 17 Nov 2009 11:24:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=jxusXo8m08OF 98wMPXZoyNFrE9U=; b=BmDTYOMg2zYLnvcatm2CZZaIwK0VVzjBelDC70kHXe82 JLB0ZKpmbpdWeAfwTNExiX1hsqfaoQqA7N1ndXM7cYw6LuBmkoZ29vvwNAIadRLQ eGRx0JQJOY+zeLxoXzH8UBLLtxaE7P97QyJUHrmGQuMOH2sD3qnA3LpIZY8zGN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=LwoKQH taWBzXaBfHFjDKgHyTFpIDIDgDlCUTCbKjLcvpdelffq4rIl0kPc8eY1SvD69vGw Krpp7mso55hs64nxytkhRVFa02nzve8RUuKYRs+IhYSyy+PbRUi4YzrqxSYH/VlI 7ZGtSF4ZMnNg44zhzmTJUwxAZJXlhmkZeR0vI= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id CA4319FB68 for ; Tue, 17 Nov 2009 11:24:29 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 5E23A9FB67 for ; Tue, 17 Nov 2009 11:24:29 -0500 (EST) Message-ID: <4B02CE81.1000607@pobox.com> Date: Tue, 17 Nov 2009 08:25:37 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> In-Reply-To: <4B02A084.9030903@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: AE6FCA14-D395-11DE-B1F7-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 16:24:32 -0000 Stephen Farrell wrote: > > Chris Newman wrote: >> --On November 16, 2009 18:25:32 +0100 Martin Rex wrote: >>> But when a proposal enters the IETF process, the IETF and the >>> working group should discuss it based on its technical merits. >> The IETF is about rough consensus and running code. Technical merit is >> one aspect of that. Time to market can be important. Technical >> maturity of the specification can be important. The best or perfect >> proposal often takes longer to develop than the good enough proposal and >> thus loses. Just look at how badly HTTP is designed when it comes to >> authentication -- but it was good enough to standardize. The HTTP >> Next-Generation working group failed because HTTP is good enough. >> >> draft-rescorla-tls-renegotiation-00 already has lots of running code; >> and that's a traditional IETF litmus test that correctly makes >> alternative proposals far less attractive. > > Having watched the recent list traffic I find the above convincing. > I'd love to see a -01 of the above containing the changes EKR has > mentioned already, and then a WGLC on that. I went back and re-read all his messages and the only change EKR suggested was to use a magic cipher suite *only as a fallback* if an initial attempt to use RI failed. All other suggestions did not convince him to make any changes. I could be wrong, but that is how the messages read. Plus I've pointed out that RI does not protect the combination of a lenient client and lenient server! This is a severe drawback since patched peers are still vulnerable during the transition period where some servers remain lenient (allow current insecure renegotiation). The following fixes that since there is no fallback needed and no reason for a client to not signal its support in every handshake. The whole point of RI is to get the previous handshake's verify_data into the handshake messages of the current session. This can be done without extensions and does not require any fallback logic. You just need three things: 1) a client-to-server signal 2) a server-to-client signal 3) somehow incorporate the previous verify_data in the handshake (1) can be achieved by simply incorporating a magic cipher suite in the ClientHello. Since that is the *only* change to the handshake, it has zero possible interoperability problems. Extensions are known to be problematic; web browsers have extremely complicated logic including reconnecting and falling back to not using extensions to try to accommodate the various server implementations. This magic cipher suite signal would be used in all handshakes since it can not cause any problems. Existing browser fallback logic would not get any more complicated. (2) can be done many ways but I think Martin came up with a better idea than the alert message I proposed. It is to toggle the upper bit of the low-order byte of the version in the ServerHello. For SSLv3, 0x0300 would become 0x0380; TLS 1.0, 0x0301 would become 0x0381, etc. This is forward-compatible too; the next version of TLS would be 4.0, 0x0400. This signal would be used in all handshakes from SSLv3 through TLS 1.2. The version in the record layer would NOT change. (3) can be done in a variety of ways. RI sends the data over the wire, but this is unnecessary since both the client and server know it already. EKR doesn't like the idea of a "virtual" handshake message, but this is an easier way to incorporate the data than requiring changes to three PRF computations (SSLv3, TLS 1.0/1.1, and TLS 1.2). I'm open to suggestions for a better (3) or even better (1) and (2), though those seem sufficiently simple. Mike From ekr@networkresonance.com Tue Nov 17 08:36:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A723A687B for ; Tue, 17 Nov 2009 08:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.574 X-Spam-Level: X-Spam-Status: No, score=0.574 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0-6IekO9jfn for ; Tue, 17 Nov 2009 08:36:33 -0800 (PST) Received: from kilo.networkresonance.com (unknown [80.169.194.194]) by core3.amsl.com (Postfix) with ESMTP id 81B043A67CC for ; Tue, 17 Nov 2009 08:36:33 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D1A1A69FA4C; Tue, 17 Nov 2009 07:07:47 +0200 (EET) Date: Tue, 17 Nov 2009 07:07:47 +0200 From: Eric Rescorla To: Nelson B Bolyard In-Reply-To: <4B022826.5080701@bolyard.me> References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022826.5080701@bolyard.me> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091117050747.D1A1A69FA4C@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 16:36:34 -0000 At Mon, 16 Nov 2009 20:35:50 -0800, Nelson B Bolyard wrote: > > On 2009-11-16 20:05 PST, Chris Newman wrote: > > > draft-rescorla-tls-renegotiation-00 already has lots of running code; and > > that's a traditional IETF litmus test that correctly makes alternative > > proposals far less attractive. > > Could we get a show of hands for working implementations of that draft? > > - I have one in NSS (used in Mozilla clients and Sun servers). > - Michael D'Errico has one. I've successfully i18y tested with it. > - Microsoft has one. I've done very limited I18y testing with it. > - OpenSSL has one, IINM. (Haven't done a test with it yet) Yes, there is one in the OpenSSL tree on the OpenSSL_0_9_8-stable branch. -Ekr From noskov@microsoft.com Tue Nov 17 08:39:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F55B3A698D for ; Tue, 17 Nov 2009 08:39:07 -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 8S2PfQwXED6P for ; Tue, 17 Nov 2009 08:39:06 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 39E733A698C for ; Tue, 17 Nov 2009 08:39:06 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 17 Nov 2009 08:39:25 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Tue, 17 Nov 2009 08:39:01 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 17 Nov 2009 08:39:01 -0800 From: Nasko Oskov To: Michael D'Errico , "tls@ietf.org" Thread-Topic: [TLS] simplistic renego protection Thread-Index: AQHKZuHMGiEOTOvqREmP25vm9DLXVpE6Lr6AgACX+ACAADbTgP//fVpw Date: Tue, 17 Nov 2009 16:38:09 +0000 Deferred-Delivery: Tue, 17 Nov 2009 16:39:00 +0000 Message-ID: References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <4B02CE81.1000607@pobox.com> In-Reply-To: <4B02CE81.1000607@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 16:39:07 -0000 Michael D'Errico wrote: >The whole point of RI is to get the previous handshake's verify_data into >the handshake messages of the current session. This can be done without >extensions and does not require any fallback logic. > >You just need three things: > > 1) a client-to-server signal > 2) a server-to-client signal > 3) somehow incorporate the previous verify_data in the handshake > >(1) can be achieved by simply incorporating a magic cipher suite in the >ClientHello. Since that is the *only* change to the handshake, it has zer= o >possible interoperability problems. Extensions are known to be >problematic; web browsers have extremely complicated logic including >reconnecting and falling back to not using extensions to try to accommodat= e >the various server implementations. This magic cipher suite signal would >be used in all handshakes since it can not cause any problems. Existing >browser fallback logic would not get any more complicated. > >(2) can be done many ways but I think Martin came up with a better idea >than the alert message I proposed. It is to toggle the upper bit of the >low-order byte of the version in the ServerHello. For SSLv3, 0x0300 would >become 0x0380; TLS 1.0, 0x0301 would become 0x0381, etc. This is >forward-compatible too; the next version of TLS would be 4.0, 0x0400. Thi= s >signal would be used in all handshakes from >SSLv3 through TLS 1.2. The version in the record layer would NOT change. > >(3) can be done in a variety of ways. RI sends the data over the wire, bu= t >this is unnecessary since both the client and server know it already. EKR >doesn't like the idea of a "virtual" handshake message, but this is an >easier way to incorporate the data than requiring changes to three PRF >computations (SSLv3, TLS 1.0/1.1, and TLS 1.2). > >I'm open to suggestions for a better (3) or even better (1) and (2), thoug= h >those seem sufficiently simple. It was indicated that some implementations use random value for the timestamp part of the random values exchanged. If this is correct and there are no interop issues with it, then we can use the timestamp as place to include a few bits as well. If we reserve the top 4 bit of the most significant byte, we can set them to predefined values to signal what we want. The side effect will be forwarding time enough in the future to allow us to move a newer version of the protocol: $ date -d @`echo "ibase=3D16; F0000000" | bc` Mon Aug 5 01:04:00 PST 2097 $ date -d @`echo "ibase=3D16; E0000000" | bc` Tue Feb 1 03:39:44 PST 2089 The benefit of using the timestamp is that it will be the same signal both ways. We don't have to alternate between cipher suites and other methods on the other way. I believe this will also be easier to implement, since new alert messages and unexpected server extensions will requre a lot more code change and case specific logic. Using two values allows both client and server to maintain the calculation of the finished message intact, but have knowledge if the handshake is expected to be initial or renegotiated. If expectations don't match, handshaking is terminated. Just an idea for signaling, since we are enumerating ideas. Nasko From uri@ll.mit.edu Tue Nov 17 09:08:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A494F3A6876 for ; Tue, 17 Nov 2009 09:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3vZBGot7ZQC for ; Tue, 17 Nov 2009 09:08:01 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id D3AB83A68DD for ; Tue, 17 Nov 2009 09:08:00 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAHH7t1a005621 for ; Tue, 17 Nov 2009 12:07:55 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAADeaau0; Tue Nov 17 11:44:54 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Tue, 17 Nov 2009 11:44:54 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "tls@ietf.org" Date: Tue, 17 Nov 2009 11:44:52 -0500 Thread-Topic: [TLS] simplistic renego protection Thread-Index: AQHKZuHMGiEOTOvqREmP25vm9DLXVpE6Lr6AgACX+ACAADbTgP//fVpwgAAB6l4= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:08:01 -0000 On 11/17/09 11:38 , "Nasko Oskov" wrote: > Michael D'Errico wrote: >> ........You just need three things: >>=20 >> 1) a client-to-server signal >> 2) a server-to-client signal >> 3) somehow incorporate the previous verify_data in the handshake >=20 > It was indicated that some implementations use random value for the > timestamp part of the random values exchanged. If this is correct and the= re > are no interop issues with it, then we can use the timestamp as place to > include a few bits as well. >From cryptographic point of view I hate seeing "timestamp" part of a random value filled with yet another random. If your [P]RNG quality is less than perfect you're seeking trouble. (And if your RNG is perfect - why did you need to put a timestamp there anyway?) --=20 Regards, Uri From mike-list@pobox.com Tue Nov 17 09:15:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA763A6986 for ; Tue, 17 Nov 2009 09:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 Tryu946IoOgk for ; Tue, 17 Nov 2009 09:15:27 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 979F93A67CC for ; Tue, 17 Nov 2009 09:15:27 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C145E801D9 for ; Tue, 17 Nov 2009 12:15:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Gxlu8yxxJYLB v3kU8byV7vtnYHw=; b=nBne99vFKDJanJk/5dqW4DxXatyLQCkNYOhAb+8sDtbt 9r88AaND5jbSzInDB170d88FLD/Hz3RzKrNPiKJBimnsF8aN1TDfFAkRxtcdtB8B 5s9oo5gCngSF7gWJMNVVVqmPTBQ8ppdpDMy1nWZi0iQBjBbY3CMhx26eb1ce89A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=VToEM9 zv9Sw8U1Y3yGxHtBI5P37PBvHChLKD2MafPOOqV72NOzPDVzb8niJRfKs/2ud69f 4Iw19CZ8I5fh7OR0X3qQD0bw2kAtz0FcxkSScMUiEtXh80SskBQZvlj2gb+Zl58j mgffokQjpeYv8QtsYP9IEgikF2PsddJraIq98= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 61D2B801D8 for ; Tue, 17 Nov 2009 12:15:25 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id DEAD2801D7 for ; Tue, 17 Nov 2009 12:15:24 -0500 (EST) Message-ID: <4B02DA71.5020202@pobox.com> Date: Tue, 17 Nov 2009 09:16:33 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <4B02CE81.1000607@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CBB26ABC-D39C-11DE-B4DA-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:15:28 -0000 Nasko Oskov wrote: > > It was indicated that some implementations use random value for the > timestamp part of the random values exchanged. If this is correct and there > are no interop issues with it, then we can use the timestamp as place to > include a few bits as well. If we reserve the top 4 bit of the most > significant byte, we can set them to predefined values to signal what we > want. The side effect will be forwarding time enough in the future to allow > us to move a newer version of the protocol: > > $ date -d @`echo "ibase=16; F0000000" | bc` > Mon Aug 5 01:04:00 PST 2097 > $ date -d @`echo "ibase=16; E0000000" | bc` > Tue Feb 1 03:39:44 PST 2089 > > The benefit of using the timestamp is that it will be the same signal both > ways. We don't have to alternate between cipher suites and other methods on > the other way. I believe this will also be easier to implement, since new > alert messages and unexpected server extensions will requre a lot more code > change and case specific logic. > > Using two values allows both client and server to maintain the calculation > of the finished message intact, but have knowledge if the handshake is > expected to be initial or renegotiated. If expectations don't match, > handshaking is terminated. > > Just an idea for signaling, since we are enumerating ideas. Since there are implementations that randomize the timestamp, then with only 4 bits, there is a 1-in-16 chance that these implementations will randomly generate one of the patterns. If the full 32 bits were used, the odds go down considerably. Two specific dates could be used, one for client and one for the server. Though personally I prefer using the cipher suite and server version (just an opinion). Mike From Yair.Elharrar@audiocodes.com Tue Nov 17 09:30:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C3E3A698C for ; Tue, 17 Nov 2009 09:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 ZGrZQu94SXMt for ; Tue, 17 Nov 2009 09:30:53 -0800 (PST) Received: from incoming.audiocodes.com (mail1.audiocodes.com [195.189.193.19]) by core3.amsl.com (Postfix) with ESMTP id 66A853A6ACD for ; Tue, 17 Nov 2009 09:30:51 -0800 (PST) Received: from unknown (HELO Mail1.AudioCodes.com) ([10.1.0.13]) by incoming.audiocodes.com with ESMTP; 17 Nov 2009 19:07:16 +0200 Received: from aclmail01.corp.audiocodes.com ([fe80:0000:0000:0000:00d9:1fca:234.186.136.40]) by aclcas.corp.audiocodes.com ([10.1.0.13]) with mapi; Tue, 17 Nov 2009 19:31:28 +0200 From: Yair Elharrar To: Michael D'Errico , "tls@ietf.org" Date: Tue, 17 Nov 2009 19:28:11 +0200 Thread-Topic: [TLS] simplistic renego protection Thread-Index: Acpnqappw+AUJDBoQMm8ql+TaiGn1AAAav4d Message-ID: References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <4B02CE81.1000607@pobox.com> , <4B02DA71.5020202@pobox.com> In-Reply-To: <4B02DA71.5020202@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:30:54 -0000 Michael D'Errico wrote: > Nasko Oskov wrote: >> >> The benefit of using the timestamp is that it will be the same signal bo= th >> ways. We don't have to alternate between cipher suites and other methods= on >> the other way. I believe this will also be easier to implement, since ne= w >> alert messages and unexpected server extensions will requre a lot more c= ode >> change and case specific logic. >> >> Using two values allows both client and server to maintain the calculati= on >> of the finished message intact, but have knowledge if the handshake is >> expected to be initial or renegotiated. If expectations don't match, >> handshaking is terminated. >> >> Just an idea for signaling, since we are enumerating ideas. > > Since there are implementations that randomize the timestamp, then with o= nly > 4 bits, there is a 1-in-16 chance that these implementations will randoml= y > generate one of the patterns. If the full 32 bits were used, the odds go > down considerably. Two specific dates could be used, one for client and = one > for the server. A few days ago I suggested using 'INIT' and 'RNEG' as fake timestamps for s= erver-to-client signaling of the current session state. Both [fake] dates h= ave passed so it's highly unlikely that they'll ever be used for anything e= lse. -- This email and any files transmitted with it are confidential material. The= y are intended solely for the use of the designated individual or entity to= whom they are addressed. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distributi= on or copying of this communication is strictly prohibited and may be unlaw= ful. If you have received this email in error please immediately notify the send= er and delete or destroy any copy of this message From dispensa@phonefactor.com Tue Nov 17 09:36:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2333A6ACD for ; Tue, 17 Nov 2009 09:36:03 -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 JiVZVWPrss6G for ; Tue, 17 Nov 2009 09:36:02 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 288E33A69F5 for ; Tue, 17 Nov 2009 09:36:02 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKSwLfANiLxGx0mIZ7mh8AvGTOfn1qeToC@postini.com; Tue, 17 Nov 2009 09:36:01 PST Received: from 10.10.10.76 ([10.10.10.76]) by pos-exch1.corp.positivenetworks.net ([204.13.120.8]) with Microsoft Exchange Server HTTP-DAV ; Tue, 17 Nov 2009 17:34:03 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 17 Nov 2009 11:35:58 -0600 From: Steve Dispensa To: Eric Rescorla , Nelson B Bolyard Message-ID: Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpnrGwm0awEW5Oh2k+d5DMCVr3G3g== In-Reply-To: <20091117050747.D1A1A69FA4C@kilo.networkresonance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:36:03 -0000 On 11/16/09 11:07 PM, "Eric Rescorla" wrote: > At Mon, 16 Nov 2009 20:35:50 -0800, > Nelson B Bolyard wrote: >> >> On 2009-11-16 20:05 PST, Chris Newman wrote: >> >>> draft-rescorla-tls-renegotiation-00 already has lots of running code; and >>> that's a traditional IETF litmus test that correctly makes alternative >>> proposals far less attractive. >> >> Could we get a show of hands for working implementations of that draft? >> >> - I have one in NSS (used in Mozilla clients and Sun servers). >> - Michael D'Errico has one. I've successfully i18y tested with it. >> - Microsoft has one. I've done very limited I18y testing with it. >> - OpenSSL has one, IINM. (Haven't done a test with it yet) > > Yes, there is one in the OpenSSL tree on the OpenSSL_0_9_8-stable > branch. There is a working GNUTLS implementation, although I'm in the process of porting it forward to the latest dev branch. -Steve From ekr@networkresonance.com Tue Nov 17 09:47:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00DA3A67A3 for ; Tue, 17 Nov 2009 09:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.535 X-Spam-Level: X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwKNb6HakQS8 for ; Tue, 17 Nov 2009 09:47:40 -0800 (PST) Received: from kilo.networkresonance.com (unknown [80.169.194.194]) by core3.amsl.com (Postfix) with ESMTP id 014613A6782 for ; Tue, 17 Nov 2009 09:47:40 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 473FC69FA4E; Tue, 17 Nov 2009 07:10:09 +0200 (EET) Date: Tue, 17 Nov 2009 07:10:09 +0200 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B01EFC4.70900@pobox.com> References: <4B01EFC4.70900@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091117051009.473FC69FA4E@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:47:40 -0000 At Mon, 16 Nov 2009 16:35:16 -0800, Michael D'Errico wrote: > > This proposed solution is a summary of many ideas from the > list, but with a twist: the server can send an alert message > to the client (I realize it's not included in the handshake > hash but that doesn't matter -- see below). This seems like a fairly unattractive idea to me. It's not what alerts were intended for and IIRC many implementations don't currently handle warning level extensions (aside from close_notify) very well. I.e., they treat them as an error. -Ekr From ekr@networkresonance.com Tue Nov 17 09:48:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0803A6782 for ; Tue, 17 Nov 2009 09:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYG3HVMnz1jt for ; Tue, 17 Nov 2009 09:48:36 -0800 (PST) Received: from kilo.networkresonance.com (unknown [80.169.194.194]) by core3.amsl.com (Postfix) with ESMTP id 1885E3A6405 for ; Tue, 17 Nov 2009 09:48:36 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 653E669FBC6; Tue, 17 Nov 2009 17:50:00 +0000 (GMT) Date: Tue, 17 Nov 2009 17:50:00 +0000 From: Eric Rescorla To: Stephen Farrell In-Reply-To: <4B02A084.9030903@cs.tcd.ie> References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091117175000.653E669FBC6@kilo.networkresonance.com> Cc: Chris Newman , tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:48:37 -0000 At Tue, 17 Nov 2009 13:09:24 +0000, Stephen Farrell wrote: > Having watched the recent list traffic I find the above convincing. > I'd love to see a -01 of the above containing the changes EKR has > mentioned already, and then a WGLC on that. I just submitted an -01 version of the draft. This includes the following changes: 1. Clarification of the encoding of the extension per the issue by Eric Young and Nelson Bolyard. 2. A bunch of discussion of fallback and the downgrade issue. 3. A SHOULD level requirement that implementations which simply reject negotiation still provide an empty extension when requested by the client, thus signalling that they have been updated. 4. A new section 4.3.1 that describes a magic cipher suite to be used to prevent downgrade attack on implementations which fall back to no extensions on handshake failure. I've left point (4) as an OPEN ISSUE because it wasn't clear to me what the WG feeling was. My general feeling is that it's not necesary: SSLv3 servers which upgrade to fix this issue by refusing renegotiation can easily arrange to simply ignore the extension, at which point no downgrade attack is possible. Servers which don't do even this can be presumed to be vulnerable and it doesn't seem that bad to simply fail in this small number of cases. That said, I don't have a problem with this feature f the WG wants to since it's not being used by negotiation but merely as a failsafe, and I thought it was important to get a concrete proposal for this mechanism on the table. -Ekr From ekr@networkresonance.com Tue Nov 17 09:50:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40873A6405 for ; Tue, 17 Nov 2009 09:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.152 X-Spam-Level: X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOCIkHgFMTzY for ; Tue, 17 Nov 2009 09:50:22 -0800 (PST) Received: from kilo.networkresonance.com (unknown [80.169.194.194]) by core3.amsl.com (Postfix) with ESMTP id 5E16D3A6843 for ; Tue, 17 Nov 2009 09:50:22 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9BE6569FBC8; Tue, 17 Nov 2009 17:51:46 +0000 (GMT) Date: Tue, 17 Nov 2009 17:51:46 +0000 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B02CE81.1000607@pobox.com> References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <4B02CE81.1000607@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091117175146.9BE6569FBC8@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:50:23 -0000 At Tue, 17 Nov 2009 08:25:37 -0800, Michael D'Errico wrote: > > Stephen Farrell wrote: > > > > Chris Newman wrote: > >> --On November 16, 2009 18:25:32 +0100 Martin Rex wrote: > >>> But when a proposal enters the IETF process, the IETF and the > >>> working group should discuss it based on its technical merits. > >> The IETF is about rough consensus and running code. Technical merit is > >> one aspect of that. Time to market can be important. Technical > >> maturity of the specification can be important. The best or perfect > >> proposal often takes longer to develop than the good enough proposal and > >> thus loses. Just look at how badly HTTP is designed when it comes to > >> authentication -- but it was good enough to standardize. The HTTP > >> Next-Generation working group failed because HTTP is good enough. > >> > >> draft-rescorla-tls-renegotiation-00 already has lots of running code; > >> and that's a traditional IETF litmus test that correctly makes > >> alternative proposals far less attractive. > > > > Having watched the recent list traffic I find the above convincing. > > I'd love to see a -01 of the above containing the changes EKR has > > mentioned already, and then a WGLC on that. > > I went back and re-read all his messages and the only change EKR > suggested was to use a magic cipher suite *only as a fallback* if > an initial attempt to use RI failed. All other suggestions did not > convince him to make any changes. I could be wrong, but that is > how the messages read. Well, the other changes I've seen suggested pretty much amount to discarding RI in favor of another approach, so I don't think it's really surprising I didn't incorporate them into RI. > Plus I've pointed out that RI does not protect the combination of a > lenient client and lenient server! This is a severe drawback since > patched peers are still vulnerable during the transition period > where some servers remain lenient (allow current insecure > renegotiation). I don't think this is entirely accurate. It doesn't protect the combination of a lenient server and a client which falls back to not using the extension at all, i.e., a client which tolerates non-compliant servers which do not properly ignore unknown extensions. Given that that's going to be a fairly small fraction of servers and that those servers are pretty much by definition unpatched (more or less the one case where you can accurately detect vulnerability without a huge number of false positives) I'm not seeing that it's a crisis to fail negotiation at this point. With that said, the extra cipher suite solves this problem AFAICT and I have no problem with adding that if it's WG consensus. > (2) can be done many ways but I think Martin came up with a better > idea than the alert message I proposed. It is to toggle the upper > bit of the low-order byte of the version in the ServerHello. For > SSLv3, 0x0300 would become 0x0380; TLS 1.0, 0x0301 would become 0x0381, > etc. This is forward-compatible too; the next version of TLS would > be 4.0, 0x0400. This signal would be used in all handshakes from > SSLv3 through TLS 1.2. The version in the record layer would NOT > change. Changing the version number in response to something other than a version number advertisement seems extremely problematic to me. > (3) can be done in a variety of ways. RI sends the data over the > wire, but this is unnecessary since both the client and server know > it already. EKR doesn't like the idea of a "virtual" handshake > message, but this is an easier way to incorporate the data than > requiring changes to three PRF computations (SSLv3, TLS 1.0/1.1, and > TLS 1.2). Well, RI doesn't require changing the PRF or the virtual -Ekr From marsh@extendedsubset.com Tue Nov 17 10:17:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E353A69C5 for ; Tue, 17 Nov 2009 10:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 0q0l9j7sjJoJ for ; Tue, 17 Nov 2009 10:17:30 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 1FFE13A69C6 for ; Tue, 17 Nov 2009 10:17:30 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NAScK-000JOw-4Z; Tue, 17 Nov 2009 18:17:28 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 6D9D0667C; Tue, 17 Nov 2009 18:17:26 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+p4gvCxNjfT7XQenFDwsKKjeLoMznnDks= Message-ID: <4B02E8B1.90905@extendedsubset.com> Date: Tue, 17 Nov 2009 12:17:21 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nasko Oskov , "tls >> \"tls@ietf.org\"" References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <4B02CE81.1000607@pobox.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 18:17:31 -0000 Nasko Oskov wrote: > > Just an idea for signaling, since we are enumerating ideas. My opinions: We should use two bits in each direction: 0. "I'm patched" 1. "I'm lenient" both default to false. For signaling in the Client Hello I like the superfluous cipher suites idea. Unless there are likely to be problems with advertising a new cipher suite. For the Server Hello I don't think there are any good options. The only bits in there which are defined to not have any existing semantics are the random_bytes (not the gmt_unix_time). We should take 4 contiguous bytes from somewhere in the middle of the 28 random bytes, and interpret them as a uint32. In this new area we use the bottom two bits as flags, and zero out the rest. These flags should be sent regardless of whether or not the client requested it. It is no one's first choice to destroy entropy from the random_bytes. However, it seems there is little alternative. The remaining 24 bytes still represent a generous amount. Although this pattern of 30 contiguous zeros could occur randomly, it would be a 1-in-one-billion occurrence. - Marsh From marsh@extendedsubset.com Tue Nov 17 10:19:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49373A69C5 for ; Tue, 17 Nov 2009 10:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 i9hbVJvuHYTp for ; Tue, 17 Nov 2009 10:19:25 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 1D7313A6841 for ; Tue, 17 Nov 2009 10:19:25 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NASeB-000Iof-8d for tls@ietf.org; Tue, 17 Nov 2009 18:19:23 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1DA13667C for ; Tue, 17 Nov 2009 18:19:22 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/CbTEPY4Y880y+4BW+edc0G/K8c064dP0= Message-ID: <4B02E925.1060805@extendedsubset.com> Date: Tue, 17 Nov 2009 12:19:17 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4B01EFC4.70900@pobox.com> <20091117051009.473FC69FA4E@kilo.networkresonance.com> In-Reply-To: <20091117051009.473FC69FA4E@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 18:19:25 -0000 Eric Rescorla wrote: > At Mon, 16 Nov 2009 16:35:16 -0800, > Michael D'Errico wrote: >> This proposed solution is a summary of many ideas from the >> list, but with a twist: the server can send an alert message >> to the client (I realize it's not included in the handshake >> hash but that doesn't matter -- see below). > > This seems like a fairly unattractive idea to me. It's not what > alerts were intended for and IIRC many implementations don't > currently handle warning level extensions (aside from > close_notify) very well. I.e., they treat them as an error. Or crash. - Marsh From ekr@networkresonance.com Tue Nov 17 10:22:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFE33A68FE for ; Tue, 17 Nov 2009 10:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpdlBJXv32wj for ; Tue, 17 Nov 2009 10:22:35 -0800 (PST) Received: from kilo.networkresonance.com (unknown [80.169.194.194]) by core3.amsl.com (Postfix) with ESMTP id 04BBA3A6841 for ; Tue, 17 Nov 2009 10:22:35 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 239D469FC11; Tue, 17 Nov 2009 18:23:59 +0000 (GMT) Date: Tue, 17 Nov 2009 18:23:58 +0000 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B02E925.1060805@extendedsubset.com> References: <4B01EFC4.70900@pobox.com> <20091117051009.473FC69FA4E@kilo.networkresonance.com> <4B02E925.1060805@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091117182359.239D469FC11@kilo.networkresonance.com> Cc: "tls@ietf.org" Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 18:22:36 -0000 At Tue, 17 Nov 2009 12:19:17 -0600, Marsh Ray wrote: > > Eric Rescorla wrote: > > At Mon, 16 Nov 2009 16:35:16 -0800, > > Michael D'Errico wrote: > >> This proposed solution is a summary of many ideas from the > >> list, but with a twist: the server can send an alert message > >> to the client (I realize it's not included in the handshake > >> hash but that doesn't matter -- see below). > > > > This seems like a fairly unattractive idea to me. It's not what > > alerts were intended for and IIRC many implementations don't > > currently handle warning level extensions (aside from > > close_notify) very well. I.e., they treat them as an error. > > Or crash. ISTM that an SSL/TLS implementation which crashes on any network input (valid or otherwise) has some pretty serious problems beyond our capacity to deal with. -Ekr From mike-list@pobox.com Tue Nov 17 10:29:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F34F3A6AE8 for ; Tue, 17 Nov 2009 10:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 s+1OnUdBBvKc for ; Tue, 17 Nov 2009 10:29:45 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id C3E503A6AE5 for ; Tue, 17 Nov 2009 10:29:45 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id ED93C80907 for ; Tue, 17 Nov 2009 13:29:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=vtzzgX8Lv5Ym 6oklLwHFKwZiT8U=; b=xCOIC3UgyDzQX15oN9wbMVKiksVIZ9mGBSNSsuaXxpwf YFv615/N7SO34NRey20eXM4ZX39OiB8sB1zqMupSb3n3uRYvq8n9RFWLQAPDTGTH VFwBUB3NfGunhOhXCGXWI/QWHDQ38E9WubznTwjTUkrki9S0Q98IoxvRVKAouz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=J6wgDO XhOn+rdvd5p+M4VgdcoWJtBwpx3Ynfd6S8DjiqC99ZFpZtpkN9eZcp0Upi/PCBSx uiNkRajPIrMYiXCE3dlv1VNndBFJ/PWOaYriVI43W+0MxIf2qthNtWGTw1XX3H58 MEKUH0BKVL6NtDjEBPOGumDpPsuuQr7d6zgps= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E9E0A80906 for ; Tue, 17 Nov 2009 13:29:43 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id A148080905 for ; Tue, 17 Nov 2009 13:29:43 -0500 (EST) Message-ID: <4B02EBDB.9060609@pobox.com> Date: Tue, 17 Nov 2009 10:30:51 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4B01EFC4.70900@pobox.com> <20091117051009.473FC69FA4E@kilo.networkresonance.com> <4B02E925.1060805@extendedsubset.com> In-Reply-To: <4B02E925.1060805@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2D35D45E-D3A7-11DE-83FA-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 18:29:46 -0000 A better alternative has been proposed which I now support, but: The alert would only be sent in response to the magic cipher suite so the client would be expecting it. If a client doesn't even have alerts working right, how can you expect them to get *extensions* right? Mike Marsh Ray wrote: > Eric Rescorla wrote: >> At Mon, 16 Nov 2009 16:35:16 -0800, >> Michael D'Errico wrote: >>> This proposed solution is a summary of many ideas from the >>> list, but with a twist: the server can send an alert message >>> to the client (I realize it's not included in the handshake >>> hash but that doesn't matter -- see below). >> This seems like a fairly unattractive idea to me. It's not what >> alerts were intended for and IIRC many implementations don't >> currently handle warning level extensions (aside from >> close_notify) very well. I.e., they treat them as an error. > > Or crash. > > - Marsh From djhopwood@googlemail.com Tue Nov 17 10:57:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2DB3A6AE7 for ; Tue, 17 Nov 2009 10:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 dg-SUdP+N09G for ; Tue, 17 Nov 2009 10:57:41 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 503453A69ED for ; Tue, 17 Nov 2009 10:57:41 -0800 (PST) Received: by bwz23 with SMTP id 23so333416bwz.29 for ; Tue, 17 Nov 2009 10:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=UeCzHoM56xb+XU8VRg4AjgsF4lmlEf/Y3MfW+/5TVbI=; b=Sz3JEXkp9EtgZCfZx3Jp7EcyAnlpKIIXOPKGOOSxTyQMPhOEdf4KTSPwkoDSDCyvgB VzvN1vGlLfJPwUUD1sZLoQsVRhHpj3YxR0HYwD8A+emFvuKlXK/5NsMKo8pQITdjEurx Sc8mgYnGNkMBfsfJL55GxXHzFZn/jOEMNb9pY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=nqiZiJMLIJsNdnqpnZMMrwiGR8YDv7FPIqOitKioSd6k3kDm2txfFQuwYsnoAFEcLn z1B/xf4qhniAVdyNGcpM7j0uS9Je+LRKVWJQUqAhDKEGtQxMBUfQB6ev0jqA1AHB5oVm JTlnlvjQDjdG+WgPbGD7vpj58/UxLKGx38rNw= Received: by 10.223.127.198 with SMTP id h6mr155606fas.102.1258484254292; Tue, 17 Nov 2009 10:57:34 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 9sm1916396fks.34.2009.11.17.10.57.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 10:57:33 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B02F21A.4050407@jacaranda.org> Date: Tue, 17 Nov 2009 18:57:30 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> <4B006D46.6070107@bolyard.me> <3B58B7A4C88EA8CA7C30C4E7@446E7922C82D299DB29D899F> <874oot3344.fsf@mocca.josefsson.org> In-Reply-To: <874oot3344.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig35A7B4D35328DBA062DB6845" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 18:57:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig35A7B4D35328DBA062DB6845 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simon Josefsson wrote: > Chris Newman writes: >=20 >> --On November 15, 2009 13:48:28 -0800 Bodo Moeller = wrote: >>> - the attack is irrelevant for opportunistic-encryption scenarios -- >> I disagree with this assertion. Opportunistic TLS for SMTP-relay is >> highly problematic. I would recommend sites disable STARTTLS for SMTP= >> relay on port 25 until they patch their TLS stacks. >=20 > How does the TLS reneg attack work for SMTP? I haven't seen it > explained anywhere, and I don't easily see how it applies. >=20 > I don't think it is wise to recommend disabling TLS without explaining > why. I agree completely. In fact I can't see how disabling TLS can possibly be= an improvement, if the alternative is a cleartext connection. > Btw, it is also not clear that the TLS reneg bug even applies to all TL= S > stacks -- for example GnuTLS requires assistance from the application t= o > do renegotiation, and most applications do not provide that assistance > with the result that TLS reneg cannot succeed. So these client/servers= > using GnuTLS are not vulnerable to the TLS reneg problem. That's a bit of an oversimplification: - If a client is using a stack that does not support renegotiation, it is still vulnerable on connections where the server will accept renegotiation. - If the server is using a stack that does not support renegotiation, it can still be vulnerable on connections where the client will accept renegotiation (subject to some other conditions). --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig35A7B4D35328DBA062DB6845 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksC8iMACgkQWUc8YzyzqAeUHgD/Sj0l9OnbPa8Cl/DYoIRxGCvE sej3MfYIlfT4BMCtD9UA/1uMQAK0jpZRwBVzJ42+Lf6hkXCZ9SyuRlGvLVBuMvbZ =z/Dn -----END PGP SIGNATURE----- --------------enig35A7B4D35328DBA062DB6845-- From simon@josefsson.org Tue Nov 17 11:15:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4394A3A6BC8 for ; Tue, 17 Nov 2009 11:15:28 -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 xcDCertmwpvd for ; Tue, 17 Nov 2009 11:15:27 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 12EB63A69C7 for ; Tue, 17 Nov 2009 11:15:26 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAHJFKKj013755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Nov 2009 20:15:22 +0100 From: Simon Josefsson To: David-Sarah Hopwood References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> <4B006D46.6070107@bolyard.me> <3B58B7A4C88EA8CA7C30C4E7@446E7922C82D299DB29D899F> <874oot3344.fsf@mocca.josefsson.org> <4B02F21A.4050407@jacaranda.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091117:tls@ietf.org::lnrBnddpDSReLs0m:OLq/ X-Hashcash: 1:22:091117:david-sarah@jacaranda.org::aObdN71txWVxeQkm:asV2 Date: Tue, 17 Nov 2009 20:15:20 +0100 In-Reply-To: <4B02F21A.4050407@jacaranda.org> (David-Sarah Hopwood's message of "Tue, 17 Nov 2009 18:57:30 +0000") Message-ID: <87hbstvu7r.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 19:15:28 -0000 David-Sarah Hopwood writes: >> Btw, it is also not clear that the TLS reneg bug even applies to all TLS >> stacks -- for example GnuTLS requires assistance from the application to >> do renegotiation, and most applications do not provide that assistance >> with the result that TLS reneg cannot succeed. So these client/servers >> using GnuTLS are not vulnerable to the TLS reneg problem. > > That's a bit of an oversimplification: > > - If a client is using a stack that does not support renegotiation, it > is still vulnerable on connections where the server will accept > renegotiation. > > - If the server is using a stack that does not support renegotiation, > it can still be vulnerable on connections where the client will > accept renegotiation (subject to some other conditions). Sure, but in your situations any security problem lies in the non-GnuTLS side right? It is the non-GnuTLS peer (if any) that needs to be patched, either to disable reneg, or to implement a secure workaround (in which case the GnuTLS peer needs to support it too for things to work again). This is why I believe the short-term fix to disable reneg is needed in OpenSSL is useful (because it, as far as I understand, it does reneg without asking the application) but the same fix is not useful for GnuTLS. If there are any applications that use rehandshake with GnuTLS, it is simpler and more appropriate to patch those application. Of course, if it turns out that a majority of GnuTLS applications are affected by this, it makes sense to fix it in GnuTLS to give protection by default. But this does not appear to be the case so far. Yes, this is a complex argument, so additional thoughts into what the GnuTLS team should do is appreciated. /Simon From djhopwood@googlemail.com Tue Nov 17 13:31:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053803A683E for ; Tue, 17 Nov 2009 13:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 YxiRdRh6MIbj for ; Tue, 17 Nov 2009 13:31:34 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 9B01F3A68B6 for ; Tue, 17 Nov 2009 13:31:34 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so109756eyd.51 for ; Tue, 17 Nov 2009 13:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=jMwaU3R2jSoLnEHMaiHMd0yIsHaGQVvQZA6oGX86imo=; b=OK25B6K1AaejldQPboOi3JusDk7oKUTfPJnjFpV7a7tk1QiMM7GcVri8l6/E/2VDDU D3isi7+5kytIJREn2BkChyKwvZTWTlaOf99j7PINYEzjeIvC2n1bouk1+BFEUtA/GXnz kGCCWJYsWW9Y684KcDWVl37ATcQCxx3gs3hXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=mcYulZ42egPPn6HK05TweyQEYfvnsNk+4AUzR4lgG9C74TZoC9eY9+SBM0k8jeDLBy LVHAcQRk0E+jX2Pc4mieqOQ3XoB5cHZOisMQh/JcZ7Cc1LqHoPEs4FI0rWT7aL6zP0fn Zrw4ziPKZZfs+PABd2wS1Gp0mwZ1t9nZKPcsw= Received: by 10.213.55.136 with SMTP id u8mr4501771ebg.51.1258493490078; Tue, 17 Nov 2009 13:31:30 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 28sm615215eyg.22.2009.11.17.13.31.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 13:31:29 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B03161D.5010905@jacaranda.org> Date: Tue, 17 Nov 2009 21:31:09 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B01EFC4.70900@pobox.com> <20091117051009.473FC69FA4E@kilo.networkresonance.com> In-Reply-To: <20091117051009.473FC69FA4E@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigCFC16A653E43B359371A2E30" Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:31:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCFC16A653E43B359371A2E30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > At Mon, 16 Nov 2009 16:35:16 -0800, > Michael D'Errico wrote: >> This proposed solution is a summary of many ideas from the >> list, but with a twist: the server can send an alert message >> to the client (I realize it's not included in the handshake >> hash but that doesn't matter -- see below). >=20 > This seems like a fairly unattractive idea to me. It's not what > alerts were intended for and IIRC many implementations don't > currently handle warning level extensions (aside from > close_notify) very well. I.e., they treat them as an error. Agreed. In general, those arguing against the use of extensions do not seem to be considering that other signalling mechanisms can potentially have interoperability problems at least as serious as extensions, and will have been less well-tested than extensions. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigCFC16A653E43B359371A2E30 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksDFiQACgkQWUc8YzyzqAfYWQD/aG9cWPm4Z+QpDuwFA85Ft+yX caRYZg9KbuqURtyGTzkA/2rvt0ZImpeL7pEED50m+AaS8R5hmsu/LfnNit+GcqDz =x1rA -----END PGP SIGNATURE----- --------------enigCFC16A653E43B359371A2E30-- From djhopwood@googlemail.com Tue Nov 17 13:39:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A903A67E9 for ; Tue, 17 Nov 2009 13:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 SLbCu-J73+yU for ; Tue, 17 Nov 2009 13:39:41 -0800 (PST) Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com [209.85.211.189]) by core3.amsl.com (Postfix) with ESMTP id 4EF103A68B6 for ; Tue, 17 Nov 2009 13:39:41 -0800 (PST) Received: by ywh27 with SMTP id 27so475074ywh.31 for ; Tue, 17 Nov 2009 13:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=xhArdXpOp/clylhn1u5T4vBUaCqAb+3ikGVASPYjCEk=; b=fviikJ+3JkcYw6UMwCtxAVTDWPhJ8j8cj9qmk1axV6EwzFjRdnyRY9crGrA6P6wPvs gPEOcgtucnfHMr+NUjVkw8+D/YjOVuRom/hYwMsu/2qFKTf1Ngjqn+dzPMxnpEYheXCh AFXPeMs1FZs7T5tKbbKcZAzTL9/5+wmpQVNrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Sv9wd9TjYcoqLpgF6sX3tN6EYW3zBFyqRiqPy3p9qJJfuoJ4pexbrbtqlDBlMnjqQi xKG8uAn+L9OaxFj2YsSM6cGDt8bE1g3ovFpvRX/iM45FmqqC7S48gDkZRkGbxfJjl3Cq wgEFjxTHaeQVoTjgFQIuIkIlCYv2FtIJitIP4= Received: by 10.213.0.142 with SMTP id 14mr2801025ebb.26.1258493975626; Tue, 17 Nov 2009 13:39:35 -0800 (PST) Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 10sm495154eyz.35.2009.11.17.13.39.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 13:39:35 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B03180A.2070306@jacaranda.org> Date: Tue, 17 Nov 2009 21:39:22 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> <4B006D46.6070107@bolyard.me> <3B58B7A4C88EA8CA7C30C4E7@446E7922C82D299DB29D899F> <874oot3344.fsf@mocca.josefsson.org> <4B02F21A.4050407@jacaranda.org> <87hbstvu7r.fsf@mocca.josefsson.org> In-Reply-To: <87hbstvu7r.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1C6C72F45F37962FF1F347AE" Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:39:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C6C72F45F37962FF1F347AE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simon Josefsson wrote: > David-Sarah Hopwood writes: >=20 >>> Btw, it is also not clear that the TLS reneg bug even applies to all = TLS >>> stacks -- for example GnuTLS requires assistance from the application= to >>> do renegotiation, and most applications do not provide that assistanc= e >>> with the result that TLS reneg cannot succeed. So these client/serve= rs >>> using GnuTLS are not vulnerable to the TLS reneg problem. >> >> That's a bit of an oversimplification: >> >> - If a client is using a stack that does not support renegotiation, i= t >> is still vulnerable on connections where the server will accept >> renegotiation. >> >> - If the server is using a stack that does not support renegotiation,= >> it can still be vulnerable on connections where the client will >> accept renegotiation (subject to some other conditions). >=20 > Sure, but in your situations any security problem lies in the non-GnuTL= S > side right? It is the non-GnuTLS peer (if any) that needs to be > patched, either to disable reneg, or to implement a secure workaround > (in which case the GnuTLS peer needs to support it too for things to > work again). Yes. I was just commenting on the statement that "*client/servers using* GnuTLS are not vulnerable", which could be misinterpreted by people less familiar with the attack. > This is why I believe the short-term fix to disable reneg is needed in > OpenSSL is useful (because it, as far as I understand, it does reneg > without asking the application) but the same fix is not useful for > GnuTLS. If there are any applications that use rehandshake with GnuTLS= , > it is simpler and more appropriate to patch those application. I'm not sure about that. If an OS distribution has several applications linked against the same shared GnuTLS library, then it might make sense to patch GnuTLS. (I'm not sure whether this is a common deployment scenar= io for GnuTLS; it is for OpenSSL.) But it seems as though a more complete fix will be available pretty soon,= anyway. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig1C6C72F45F37962FF1F347AE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksDGAoACgkQWUc8YzyzqAcNUAEAoOvGP2wIuCN91LI3PQUAtzmT URiJHOUFH915fsbNlewA/0JE2zWbM5KyqhWT2UmouR+PnEnDYfPRGw5ksrPjFZXW =ds6N -----END PGP SIGNATURE----- --------------enig1C6C72F45F37962FF1F347AE-- From lists@drh-consultancy.demon.co.uk Tue Nov 17 13:50:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABC43A6B0D for ; Tue, 17 Nov 2009 13:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 a7XerOB2VQmK for ; Tue, 17 Nov 2009 13:50:10 -0800 (PST) Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by core3.amsl.com (Postfix) with ESMTP id 979C53A6AFF for ; Tue, 17 Nov 2009 13:50:09 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49904 helo=[192.168.7.8]) by relay03.mail.eu.clara.net (relay.clara.net [213.253.3.43]:10587) with esmtpa (authdaemon_plain:drh) id 1NAVw4-0000Iw-AH (Exim 4.69) for tls@ietf.org (return-path ); Tue, 17 Nov 2009 21:50:04 +0000 Message-ID: <4B031A8F.7010000@drh-consultancy.demon.co.uk> Date: Tue, 17 Nov 2009 21:50:07 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B01EFC4.70900@pobox.com> <20091117051009.473FC69FA4E@kilo.networkresonance.com> <4B03161D.5010905@jacaranda.org> In-Reply-To: <4B03161D.5010905@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:50:11 -0000 David-Sarah Hopwood wrote: > Eric Rescorla wrote: >> At Mon, 16 Nov 2009 16:35:16 -0800, >> Michael D'Errico wrote: >>> This proposed solution is a summary of many ideas from the >>> list, but with a twist: the server can send an alert message >>> to the client (I realize it's not included in the handshake >>> hash but that doesn't matter -- see below). >> This seems like a fairly unattractive idea to me. It's not what >> alerts were intended for and IIRC many implementations don't >> currently handle warning level extensions (aside from >> close_notify) very well. I.e., they treat them as an error. > > Agreed. In general, those arguing against the use of extensions do > not seem to be considering that other signalling mechanisms can > potentially have interoperability problems at least as serious as > extensions, and will have been less well-tested than extensions. > Well to add a data point for OpenSSL... TLS extensions were disabled by default in all released versions of OpenSSL until 0.9.8j released on 07 Jan 2009. A (relatively small) number of issues were reported relating to SSLv3 servers not handling extensions. It is hard to gauge how many are affected because people will sometimes just read and adopt the "solution" (disable extensions) and consider the job done. By contrast I've never (in over 10+ years) come across a server that needed a ciphersuite advertised in client Hello removed that it didn't actually negotiate. Historically all sorts of unusual ciphersuites had been advertised in SSLv3 (Fortezza and custom FIPS140-2 ones spring to mind). Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From simon@josefsson.org Tue Nov 17 13:58:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25DA28C0DB for ; Tue, 17 Nov 2009 13:58:45 -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 3InKlmY81Bnz for ; Tue, 17 Nov 2009 13:58:45 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 921973A680F for ; Tue, 17 Nov 2009 13:58:44 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAHLwdpD017127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Nov 2009 22:58:41 +0100 From: Simon Josefsson To: David-Sarah Hopwood References: <4AFF79A4.6020706@extendedsubset.com> <20091115111834.334A869F79B@kilo.networkresonance.com> <4B006D46.6070107@bolyard.me> <3B58B7A4C88EA8CA7C30C4E7@446E7922C82D299DB29D899F> <874oot3344.fsf@mocca.josefsson.org> <4B02F21A.4050407@jacaranda.org> <87hbstvu7r.fsf@mocca.josefsson.org> <4B03180A.2070306@jacaranda.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091117:tls@ietf.org::TaNuIhhAERuNuuQ1:FZ/h X-Hashcash: 1:22:091117:david-sarah@jacaranda.org::lPuDy/j6vJ3LZS7B:Aq56 Date: Tue, 17 Nov 2009 22:58:39 +0100 In-Reply-To: <4B03180A.2070306@jacaranda.org> (David-Sarah Hopwood's message of "Tue, 17 Nov 2009 21:39:22 +0000") Message-ID: <87lji4u834.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:58:45 -0000 David-Sarah Hopwood writes: > Simon Josefsson wrote: >> David-Sarah Hopwood writes: >> >>>> Btw, it is also not clear that the TLS reneg bug even applies to all TLS >>>> stacks -- for example GnuTLS requires assistance from the application to >>>> do renegotiation, and most applications do not provide that assistance >>>> with the result that TLS reneg cannot succeed. So these client/servers >>>> using GnuTLS are not vulnerable to the TLS reneg problem. >>> >>> That's a bit of an oversimplification: >>> >>> - If a client is using a stack that does not support renegotiation, it >>> is still vulnerable on connections where the server will accept >>> renegotiation. >>> >>> - If the server is using a stack that does not support renegotiation, >>> it can still be vulnerable on connections where the client will >>> accept renegotiation (subject to some other conditions). >> >> Sure, but in your situations any security problem lies in the non-GnuTLS >> side right? It is the non-GnuTLS peer (if any) that needs to be >> patched, either to disable reneg, or to implement a secure workaround >> (in which case the GnuTLS peer needs to support it too for things to >> work again). > > Yes. I was just commenting on the statement that "*client/servers using* > GnuTLS are not vulnerable", which could be misinterpreted by people less > familiar with the attack. Right. The "these" was significant generally speaking. However, it appears as if your application use GnuTLS in both client and server, and the application does not have code to do TLS reneg (which appears to be what the majority of all GnuTLS applications out there does) you are not vulnerable. >> This is why I believe the short-term fix to disable reneg is needed in >> OpenSSL is useful (because it, as far as I understand, it does reneg >> without asking the application) but the same fix is not useful for >> GnuTLS. If there are any applications that use rehandshake with GnuTLS, >> it is simpler and more appropriate to patch those application. > > I'm not sure about that. If an OS distribution has several applications > linked against the same shared GnuTLS library, then it might make sense > to patch GnuTLS. (I'm not sure whether this is a common deployment scenario > for GnuTLS; it is for OpenSSL.) Right, but few (if any) applications linked dynamically with GnuTLS appears to be vulnerable. I believe one needs to look at each of the applications individually. If there is a pattern in them that they are buggy in the same way, the problem should be fixed in GnuTLS. But if there is no pattern in the problems, or even any vulnerable applications at all, it does not make sense to do anything in GnuTLS. This investigation has been done for OpenSSL, and for it there is a clear pattern that applications are vulnerable, and a fix was made for OpenSSL. But the same pattern doesn't seem to exists in GnuTLS applications. > But it seems as though a more complete fix will be available pretty soon, > anyway. Right, but I'm not sure it makes sense to release a security upgrade of GnuTLS with that extension. Doing so would not fix any known vulnerable application, or we would have to act today by disabling tls reneg for that particular application while we wait. So the extension would be like any new feature in a future stable branch. /Simon From mike-list@pobox.com Tue Nov 17 15:16:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD8E28C197 for ; Tue, 17 Nov 2009 15:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 OXKdpv2uSz+1 for ; Tue, 17 Nov 2009 15:16:09 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 952D23A6AF1 for ; Tue, 17 Nov 2009 15:16:09 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C6EC3808B8 for ; Tue, 17 Nov 2009 18:16:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=rm9kyK9XiP+iiHvTa+wRoSdQd ik=; b=EbcnrfwEbPFH0QfeEXDtOJiQ0+xahWyTe/vFpjYLovfLpZEzy10jnSElW vxJOpv4PIT4K4EKlnDCta+yKdIX1apOqyGpuMhg4SdK15CR5WlNiifICjlmCUIFP OjEtasesKycm2HPHL7kmiuctLw9XXhW7repUuv9fkXZQNQkGRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=B4KAXg+INiQ6VY25IFD MyLOKk/noj0gQ10fWsVIos+uW1R4G7sEkE2jawxSb9crlH7YdyPHGtivjzdEszlb 1bBU6+S8O9OXqaCp5sli2dfIqdZez3gIlVTN+jrdlyTBUVKtm0MFjYNsV6MNepkW rIyaaOxl4w3kUL4iLGVO6xZw= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5EC52808B7 for ; Tue, 17 Nov 2009 18:16:07 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id D53D7808B6 for ; Tue, 17 Nov 2009 18:16:06 -0500 (EST) Message-ID: <4B032EFC.6050707@pobox.com> Date: Tue, 17 Nov 2009 15:17:16 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2F54B99E-D3CF-11DE-9D8B-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] Implementation Experience X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:16:11 -0000 I have some hard numbers to share regarding implementation of the RI extension and the alternate proposal given below. I initially implemented the RI extension in my code and based on the CVS logs, the net addition of code was 248 lines of C++. Just this morning I ripped out the RI extension and instead implemented the alternate proposal. Based on the CVS logs there was a net decrease of 91 lines of code. That means RI requires 58% MORE CODE in a codebase that already fully supports TLS extensions. In addition, RI practically requires implementing fallback code, which I did not add, so I would bet RI requires at least double the amount of code as this alternate proposal, and possibly a lot more given the myriad possible fallback scenarios. I will be installing this change on my test server shortly for anyone to test against. Mike ----------------------------------------------------------- Alternate proposal to RI: - Client includes a special cipher suite as the first in its cipher suite list. The value chosen for testing: 0xBFFF (the last of the "Standards Action" cipher suites -- I'm pretty sure I've seen 0xFEFF used in the wild) - Upon seeing this marker, the server does the following: a) sets the high bit of the low byte of the version returned in ServerHello -- this indicates to the client that the server recognized the special cipher suite -- the record layer version uses the normal version number without the high bit set; Examples: SSLv3: 0x0380 TLS 1.0: 0x0381 TLS 1.1: 0x0382 TLS 1.2: 0x0383 b) adds to the Handshake Hash the PreviousVerifyData structure (see below) immediately following ServerHello; only the PreviousVerifyData is added, it is not wrapped to look like a handshake message with a type and length. - Upon noticing the high bit of the low byte of the server's version being set, the client does the following: a) resets the high bit of the low byte of the version to be used for the record layer version b) adds to the Handshake Hash the PreviousVerifyData structure immediately following ServerHello A server would obviously not renegotiate if the magic cipher suite is not present in the renegotiation ClientHello. If it is present but is actually a proxied initial handshake through a MITM, the PreviousVerifyData used by client and server will be different and thus the handshake will fail and the attack prevented. PreviousVerifyData structure: struct { opaque previous_client_verify_data<0..255>; opaque previous_server_verify_data<0..255>; } PreviousVerifyData; The PreviousVerifyData on the initial handshake would be just two zero bytes, one for each of the lengths of the opaque vectors. When renegotiating, it will look like: 0x0C [12 client verify data bytes] 0x0C [12 server bytes] for a total of 26 bytes added to the handshake hash. From nelson@bolyard.me Tue Nov 17 15:31:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DCA3A69C3 for ; Tue, 17 Nov 2009 15:31:14 -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 Wq8+IDSFwTzI for ; Tue, 17 Nov 2009 15:31:13 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id CEFE43A67DA for ; Tue, 17 Nov 2009 15:31:13 -0800 (PST) Received: (qmail 23785 invoked from network); 17 Nov 2009 23:31:10 -0000 Received: from unknown (192.18.120.70) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 17 Nov 2009 23:31:10 -0000 Message-ID: <4B03323C.7020900@bolyard.me> Date: Tue, 17 Nov 2009 15:31:08 -0800 From: Nelson Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 SeaMonkey/1.5a MIME-Version: 1.0 To: tls@ietf.org References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <4AFF0153.3090005@bolyard.me> <3EFE80FB-AB07-4BB3-ABDD-E836D27B7E54@acm.org> <4B01B1D5.3030005@bolyard.me> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:31:15 -0000 Bodo Moeller wrote: > On Nov 16, 2009, at 12:11 PM, Nelson B Bolyard wrote: >> On 2009-11-15 11:13 PDT, Bodo Moeller wrote: >>> On Nov 14, 2009, at 11:13 AM, Nelson B Bolyard wrote: > >>>> Others in the meeting responded that changing the definition of the >>>> computation of the Finished messages was a change to the base protocol >>>> specification (which adding an extension is not), and thus the change >>>> I proposed would make TLS become (say) TLS 1.3. >>> >>> In that proposal, would there have been any explicit indicator sent by >>> the client and server to indicate that they intend to use the the >>> modified Finished message? >> >> Yes, the protocol version number. > > Well, obviously -- I was asking about the proposal *before* others had > suggested that this would require a new protocol version. > > I gather that there was no other indicator, and *thus* they thought the > protocol version would have to change. I had something else in mind, but I never presented it, because I concurred with the assessment that it was a base protocol change and really deserved a new protocol version number. From rwilliams@certicom.com Tue Nov 17 15:31:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EE63A69C3 for ; Tue, 17 Nov 2009 15:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 WB8QpzVmK-ta for ; Tue, 17 Nov 2009 15:31:55 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id EBF1228C194 for ; Tue, 17 Nov 2009 15:31:47 -0800 (PST) X-AuditID: 0a666446-b7b5eae0000003bc-38-4b0332611b47 Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id C9.44.00956.162330B4; Tue, 17 Nov 2009 18:31:45 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 18:31:44 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Tue, 17 Nov 2009 18:30:52 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC40251FF48@XCH57YKF.rim.net> In-Reply-To: <87lji4u834.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Non-extension solutions (requirements) Thread-Index: Acpn0SOeUCEUTEUsQQ2IL5zB2CdzQwACPdsQ References: <4AFF79A4.6020706@extendedsubset.com><20091115111834.334A869F79B@kilo.networkresonance.com><4B006D46.6070107@bolyard.me><3B58B7A4C88EA8CA7C30C4E7@446E7922C82D299DB29D899F><874oot3344.fsf@mocca.josefsson.org> <4B02F21A.4050407@jacaranda.org><87hbstvu7r.fsf@mocca.josefsson.org> <4B03180A.2070306@jacaranda.org> <87lji4u834.fsf@mocca.josefsson.org> From: "Rob P Williams" To: "Simon Josefsson" , "David-Sarah Hopwood" X-OriginalArrivalTime: 17 Nov 2009 23:31:44.0949 (UTC) FILETIME=[1FECBE50:01CA67DE] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: tls@ietf.org Subject: Re: [TLS] Non-extension solutions (requirements) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:31:56 -0000 > > > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Simon Josefsson > Sent: Tuesday, November 17, 2009 4:59 PM > To: David-Sarah Hopwood > Cc: tls@ietf.org > Subject: Re: [TLS] Non-extension solutions (requirements) > > David-Sarah Hopwood writes: > > > Simon Josefsson wrote: > >> David-Sarah Hopwood writes: > >> > >>>> Btw, it is also not clear that the TLS reneg bug even applies to all TLS > >>>> stacks -- for example GnuTLS requires assistance from the application to > >>>> do renegotiation, and most applications do not provide that assistance > >>>> with the result that TLS reneg cannot succeed. So these client/servers > >>>> using GnuTLS are not vulnerable to the TLS reneg problem. > >>> > >>> That's a bit of an oversimplification: > >>> > >>> - If a client is using a stack that does not support renegotiation, it > >>> is still vulnerable on connections where the server will accept > >>> renegotiation. > >>> > >>> - If the server is using a stack that does not support renegotiation, > >>> it can still be vulnerable on connections where the client will > >>> accept renegotiation (subject to some other conditions). > >> > >> Sure, but in your situations any security problem lies in the non-GnuTLS > >> side right? It is the non-GnuTLS peer (if any) that needs to be > >> patched, either to disable reneg, or to implement a secure workaround > >> (in which case the GnuTLS peer needs to support it too for things to > >> work again). > > > > Yes. I was just commenting on the statement that "*client/servers using* > > GnuTLS are not vulnerable", which could be misinterpreted by people less > > familiar with the attack. > > Right. The "these" was significant generally speaking. However, it > appears as if your application use GnuTLS in both client and server, and > the application does not have code to do TLS reneg (which appears to be > what the majority of all GnuTLS applications out there does) you are not > vulnerable. > > >> This is why I believe the short-term fix to disable reneg is needed in > >> OpenSSL is useful (because it, as far as I understand, it does reneg > >> without asking the application) but the same fix is not useful for > >> GnuTLS. If there are any applications that use rehandshake with GnuTLS, > >> it is simpler and more appropriate to patch those application. > > > > I'm not sure about that. If an OS distribution has several applications > > linked against the same shared GnuTLS library, then it might make sense > > to patch GnuTLS. (I'm not sure whether this is a common deployment scenario > > for GnuTLS; it is for OpenSSL.) > > Right, but few (if any) applications linked dynamically with GnuTLS > appears to be vulnerable. I believe one needs to look at each of the > applications individually. If there is a pattern in them that they are > buggy in the same way, the problem should be fixed in GnuTLS. But if > there is no pattern in the problems, or even any vulnerable applications > at all, it does not make sense to do anything in GnuTLS. > > This investigation has been done for OpenSSL, and for it there is a > clear pattern that applications are vulnerable, and a fix was made for > OpenSSL. But the same pattern doesn't seem to exists in GnuTLS > applications. > > > But it seems as though a more complete fix will be available pretty soon, > > anyway. > > Right, but I'm not sure it makes sense to release a security upgrade of > GnuTLS with that extension. Doing so would not fix any known vulnerable > application, or we would have to act today by disabling tls reneg for > that particular application while we wait. So the extension would be > like any new feature in a future stable branch. Hopefully - that security upgrade is already under development. Don't the unknown applications that are using GnuTLS deserve immediate protection too? You cannot assume that your peer's version of any application is using a specific TLS stack. You cannot prove that you are talking to a peer that is immune to this attack. GnuTLS needs the extension*. Any TLS implementation that doesn't move forward with the extension will remain vulnerable. * or whatever the IETF agrees upon. -- rob | Software Developer Certicom Corp. | A susbidiary of Research In Motion Limited main | +1 905-507-4220 direct | +1 905-501-3887 rwilliams@certicom.com www.certicom.com ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From mrex@sap.com Tue Nov 17 17:28:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DFF3A6826 for ; Tue, 17 Nov 2009 17:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.244, 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 IVKkL44BQ-b0 for ; Tue, 17 Nov 2009 17:28:11 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A42693A67E5 for ; Tue, 17 Nov 2009 17:28:10 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAI1S70h027865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 02:28:07 +0100 (MET) From: Martin Rex Message-Id: <200911180128.nAI1S6K6007918@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Wed, 18 Nov 2009 02:28:06 +0100 (MET) In-Reply-To: <4B03161D.5010905@jacaranda.org> from "David-Sarah Hopwood" at Nov 17, 9 09:31:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 01:28:11 -0000 David-Sarah Hopwood wrote: > > Michael D'Errico wrote: > >> This proposed solution is a summary of many ideas from the > >> list, but with a twist: the server can send an alert message > >> to the client (I realize it's not included in the handshake > >> hash but that doesn't matter -- see below). > > > > This seems like a fairly unattractive idea to me. It's not what > > alerts were intended for and IIRC many implementations don't > > currently handle warning level extensions (aside from > > close_notify) very well. I.e., they treat them as an error. > > Agreed. In general, those arguing against the use of extensions do > not seem to be considering that other signalling mechanisms can > potentially have interoperability problems at least as serious as > extensions, and will have been less well-tested than extensions. I privately told Michael that personally I'm against the idea of using alerts, because these are often processed in completely different code paths of the implementations, and some of the existing implementations seems to have significant difficulties dealing with SSL alerts. That includes delivering Alerts to the network or continuing after warning-level alerts (with very few exemptions, like the no_certificate alert). Microsoft SSL/TLS implementation seems to be a little stingy when it comes to sending alerts. ;) The most appropriate location for signaling security parameters from server to client is ServerHello. -Martin From mike-list@pobox.com Tue Nov 17 19:25:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60BA3A6A25 for ; Tue, 17 Nov 2009 19:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 ntnAeaAQwcb7 for ; Tue, 17 Nov 2009 19:25:44 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 04BB63A67FC for ; Tue, 17 Nov 2009 19:25:43 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2AAEC80F3C for ; Tue, 17 Nov 2009 22:25:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=VjvghPcBkiXL T+koCCZuWDsAi6E=; b=RUN6WN0tGy4CeNX6qp67UTaM7hqSNE0FlzV41z9ph+H+ SqAQY4+TcY9EoSg84ru1ba9GZCrVyv8Iwr+bTd9FznBZsWflWcPZs6HWZkZin9ar QN8rv5n8gQd8U0snk8mtQNw3rDOODtz+JMkK082zQslov0+zZt9RhGOfZwsrDo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=jmbAGp YQomZK6DueK++rM3st85h1PXpp7NeH/xsl43wLCWLtwoE5C5z7SXODV7asjUzJuw +JFpuBvLkDnvHScuDjeayqD7iNRM8R6py4C+EeMJY1ETDx/3IA7Z2eI8jEvqwZfN DdPeTyWUBEJMBKWuE2EFhhZlehT342STTBj3A= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 240B880F3B for ; Tue, 17 Nov 2009 22:25:42 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id AF55880F3A for ; Tue, 17 Nov 2009 22:25:41 -0500 (EST) Message-ID: <4B03697C.80108@pobox.com> Date: Tue, 17 Nov 2009 19:26:52 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911180128.nAI1S6K6007918@fs4113.wdf.sap.corp> In-Reply-To: <200911180128.nAI1S6K6007918@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 0CFD4D66-D3F2-11DE-A5BA-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:25:45 -0000 Martin Rex wrote: > David-Sarah Hopwood wrote: >>> Michael D'Errico wrote: >>>> This proposed solution is a summary of many ideas from the >>>> list, but with a twist: the server can send an alert message >>>> to the client (I realize it's not included in the handshake >>>> hash but that doesn't matter -- see below). >>> This seems like a fairly unattractive idea to me. It's not what >>> alerts were intended for and IIRC many implementations don't >>> currently handle warning level extensions (aside from >>> close_notify) very well. I.e., they treat them as an error. >> Agreed. In general, those arguing against the use of extensions do >> not seem to be considering that other signalling mechanisms can >> potentially have interoperability problems at least as serious as >> extensions, and will have been less well-tested than extensions. > > > I privately told Michael that personally I'm against the idea of > using alerts, because these are often processed in completely > different code paths of the implementations, and some of > the existing implementations seems to have significant difficulties > dealing with SSL alerts. That includes delivering Alerts to > the network or continuing after warning-level alerts (with very > few exemptions, like the no_certificate alert). > > Microsoft SSL/TLS implementation seems to be a little stingy > when it comes to sending alerts. ;) > > The most appropriate location for signaling security parameters > from server to client is ServerHello. After Martin suggested using the server version to signal the server's support, I could see that it was far simpler than an alert message, so I *changed my mind* and went with that in the code I implemented this morning. That is what engineers do. They don't run with ideas simply because they came up with them when there have been serious problems pointed out. Remember there is an E in IETF! Not a P (political), but an E. Mike From marsh@extendedsubset.com Tue Nov 17 19:30:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F1C3A6821 for ; Tue, 17 Nov 2009 19:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 DjavLJC67lvi for ; Tue, 17 Nov 2009 19:30:35 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 0D4673A62C1 for ; Tue, 17 Nov 2009 19:30:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NAbFZ-0007t4-5v for tls@ietf.org; Wed, 18 Nov 2009 03:30:33 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4ADCF667C for ; Wed, 18 Nov 2009 03:30:31 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+nNn/PNBqraqI0S/e6I9865zR003V6VyY= Message-ID: <4B036A56.5080801@extendedsubset.com> Date: Tue, 17 Nov 2009 21:30:30 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911180128.nAI1S6K6007918@fs4113.wdf.sap.corp> <4B03697C.80108@pobox.com> In-Reply-To: <4B03697C.80108@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:30:35 -0000 Michael D'Errico wrote: > > After Martin suggested using the server version to signal the > server's support, I could see that it was far simpler than an > alert message, so I *changed my mind* and went with that in the > code I implemented this morning. Couldn't all the signaling could be solved with the version number fields? Problem is, that's the one field that every client, server, and inspecting firewall is looking at most closely. How will they react? My intuition/experience suggests that touching those fields will break lots of stuff. - Marsh From mike-list@pobox.com Tue Nov 17 19:58:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB3A3A6A22 for ; Tue, 17 Nov 2009 19:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 9qWvomMfE+9P for ; Tue, 17 Nov 2009 19:58:14 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 74AE33A69E8 for ; Tue, 17 Nov 2009 19:58:14 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 815DF801FD for ; Tue, 17 Nov 2009 22:58:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=cPh7bJWqIHMq 2linH3TDt8B7Is0=; b=mvPlkK3XFUS5/Ok7D/BMiAIuNwWBGZ6wP/7vAlXmyY47 3FSHdqXoJlfUIPd2aR62DL98wjvDgL9r4JultdJDLcgPDIQQtMrOXSsBR7jdNefn vsfvuwnmCxLUhy+L+hlQUuNoW6qo09zIXzo8ok4HTvktrcfSdCVaNn5Rh6F2+K8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=OeGsTC ATXhm+bHLfIvERFqYQaQvECDKVTsnv7x77dQklfw5svGNuiSZINDgBElkpDHqynq L0h90DegKIm/MVc6nCp5l1gNhFYa63TIrSZLExja1FjvneYbWKqg65Bj/nEVz1C4 OUlrXn33YTfN6U+cVyhknSW+xHVQWltLKXN+E= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7D6D1801FC for ; Tue, 17 Nov 2009 22:58:12 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 0EC09801FB for ; Tue, 17 Nov 2009 22:58:11 -0500 (EST) Message-ID: <4B03711A.9080108@pobox.com> Date: Tue, 17 Nov 2009 19:59:22 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911180128.nAI1S6K6007918@fs4113.wdf.sap.corp> <4B03697C.80108@pobox.com> <4B036A56.5080801@extendedsubset.com> In-Reply-To: <4B036A56.5080801@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 977EA198-D3F6-11DE-AC8B-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 03:58:15 -0000 Marsh Ray wrote: > Michael D'Errico wrote: >> After Martin suggested using the server version to signal the >> server's support, I could see that it was far simpler than an >> alert message, so I *changed my mind* and went with that in the >> code I implemented this morning. > > Couldn't all the signaling could be solved with the version number fields? I don't think so. An unpatched server won't know what the new version numbers mean if a client were to send them. It would think the client supports some version beyond TLS 1.2. If the client is really a TLS 1.0 client + patch, and the server selects TLS 1.1 (its max version), then you have an interoperability problem. > Problem is, that's the one field that every client, server, and > inspecting firewall is looking at most closely. How will they react? > > My intuition/experience suggests that touching those fields will break > lots of stuff. Well the only clients and servers that will ever see/use them are those that are patched, so they are not a problem. If there is a serious problem with firewalls or other monitoring software, we can find a different signal. But on the other hand, firewalls and monitoring software will want to be updated to look for patched SSL/TLS clients and servers. Using the version the way Martin suggested is easy to check -- you just test a single bit in the server hello at a fixed offset. Consider monitoring software that needs to check for the RI extension in the ServerHello extensions; there is currently no mandate for the location of RI within the list, so the list must be parsed. Okay, so you can say it MUST be first, but that is yet another band-aid on a bad solution. Mike From mrex@sap.com Tue Nov 17 20:15:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50C13A68B7 for ; Tue, 17 Nov 2009 20:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.235, 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 NfE8MRDxSQUQ for ; Tue, 17 Nov 2009 20:15:59 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C90E03A6817 for ; Tue, 17 Nov 2009 20:15:58 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAI4FrBS004238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 05:15:53 +0100 (MET) From: Martin Rex Message-Id: <200911180415.nAI4Frd9017599@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 18 Nov 2009 05:15:53 +0100 (MET) In-Reply-To: <4B036A56.5080801@extendedsubset.com> from "Marsh Ray" at Nov 17, 9 09:30:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Server can send an alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 04:16:00 -0000 Marsh Ray wrote: > > Michael D'Errico wrote: > > > > After Martin suggested using the server version to signal the > > server's support, I could see that it was far simpler than an > > alert message, so I *changed my mind* and went with that in the > > code I implemented this morning. > > Couldn't all the signaling could be solved with the version number fields? > > Problem is, that's the one field that every client, server, and > inspecting firewall is looking at most closely. How will they react? > > My intuition/experience suggests that touching those fields will break > lots of stuff. I do hope that the firewalls and IDS systems out there are not going to kill my prefered approach to use the ServerHello.server_version field for signaling back from Server to Client. I would prefer to re-purpose the bits from the top. That signal is supposed to appear only in ServerHello.server_version and nowhere else in protocol version fields, in particular _not_ in the record layer. The PDU data visualization in network sniffers like Wireshark will likely need to learn the new number, but that should not be an unsurmountable problem. If we're considering making the secure renegotiation a requirement for the next TLS protocol rev. (prohibiting the insecure renegotiation when TLSv1.3 is negotiated), then it is much better when the protocol version related code is fairly colocated. The server-side code that builds ServerHello.server_version into the PDU and the client-side code that parses the ServerHello.server_version from the PDU seems fairly natural to me. -Martin From peter.robinson@rsa.com Tue Nov 17 20:41:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB6C3A68A3 for ; Tue, 17 Nov 2009 20:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.434, 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 BLjy9ZZn-+Dn for ; Tue, 17 Nov 2009 20:41:03 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E4FF33A6838 for ; Tue, 17 Nov 2009 20:41:02 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nAI4f0tU005361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Nov 2009 23:41:00 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Tue, 17 Nov 2009 23:40:54 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2mp) with ESMTP id nAI4er0U000811 for ; Tue, 17 Nov 2009 23:40:54 -0500 Received: from CORPUSMX100B.corp.emc.com ([128.222.76.52]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 23:40:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Nov 2009 23:40:51 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_102C_01CA685D.1FCAC4B0" Message-ID: In-Reply-To: <200911180415.nAI4Frd9017599@fs4113.wdf.sap.corp> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: TLS Protocol Version Thread-Index: AcpoBdrWLz6VHvNzREe95pcdl83+MQAAT2zA References: <4B036A56.5080801@extendedsubset.com> from "Marsh Ray" at Nov 17, 9 09:30:30 pm <200911180415.nAI4Frd9017599@fs4113.wdf.sap.corp> From: To: X-OriginalArrivalTime: 18 Nov 2009 04:40:53.0857 (UTC) FILETIME=[4FEF7D10:01CA6809] X-EMM-EM: Active Subject: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 04:41:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_102C_01CA685D.1FCAC4B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There have been several posts which have discussed the possibility of re-using existing fields, rather than use the TLS extension mechanism. Using a field for anything but its intended purpose is fraught with danger. In particular, there has been discussion of re-purposing of bits of the TLS Protocol Version. Our server code uses the TLS Protocol Version as a numeric value to negotiate the TLS version. If a client offers TLS 1.0 (3,1) and the server can do TLS 1.2 (3,3), the server determines that TLS 1.0 (3,1) is less than TLS 1.2 (3.3), and then chooses TLS 1.0 (3,1). If the decision was to signal via the top bit of the protocol version, then an updated client might offer TLS 1.0 patched (0x83, 1) and a not updated server can do TLS 1.2 (3,3), the server determines that TLS 1.0patched (0x83,1) is greater than TLS 1.2 (3,3), and then chooses TLS 1.2 (3,3)! ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. ------=_NextPart_000_102C_01CA685D.1FCAC4B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWmzCCAucw ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1 s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5 IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3 Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/ eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5 /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1 cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13 qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggR+MIID56ADAgECAhEAsSe9 yNTH2rYKRiN7F8KhkTANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT MB4XDTA5MDcyMTA1MTYxM1oXDTExMDcyMjA1MTYxM1owgekxEzARBgoJkiaJk/IsZAEZFgNjb20x EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjEMMAoGA1UECxMD UlNBMRUwEwYDVQQLEwxBc2lhL1BhY2lmaWMxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQF EwYwNjQ4MTQxFzAVBgoJkiaJk/IsZAEBEwdyb2JpbnAyMRcwFQYDVQQDEw5QZXRlciBSb2JpbnNv bjElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA2CcjIV2QNoJP4YbPejhZX2MSu53/EooTnrkf7M4gsl1DobXkk3CO6kU9bN6O wwL/o87dQ4y2FHjwkV4WeoodhvZa08q5uX4vZCtB2Hn0OUrbPzyKl7wXSq+yezKCQJBrVCTwWjKK A6Gqc1VhkqWSBCpUaQ39TsVDxNYCGIn433cCAwEAAaOCAX8wggF7MIGSBgNVHSAEgYowgYcwgYQG CSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5o dG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9y YXRlZCBieSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnBldGVyLnJvYmluc29uQHJzYS5jb20wDgYDVR0PAQH/BAQDAgeAMEYG A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQm 7p962rS9dUpGeQZt+Vi1su6tQTANBgkqhkiG9w0BAQUFAAOBgQCghPP5wxcDJuACPYJ/U1sjhyE4 gxpGKZNPnnDcjfHo+Cq87cWawpV5Rzpg8KVZc0EoG6BabGNyk+WgZMjCzADpg+appN4cX+DML0ir 3cBcX8pQTuKw1VRlUjidjkTIl/Z2hrcvgh2lJG+PFV2ogWICzwOj4/zKG4khs9VO5NNPezCCBI4w ggP3oAMCAQICEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFS U0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xh c3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czELMAkGA1UEBhMCVVMwHhcNMDkwNzIxMDUxNjE4WhcNMTEwNzIyMDUxMzM2WjCB7TETMBEGCgmS JomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0 aW9uMQwwCgYDVQQLEwNSU0ExFTATBgNVBAsTDEFzaWEvUGFjaWZpYzEUMBIGA1UECxMLRW5naW5l ZXJpbmcxDzANBgNVBAUTBjA2NDgxNDEXMBUGCgmSJomT8ixkAQETB3JvYmlucDIxGzAZBgNVBAMT ElBldGVyIFJvYmluc29uLUVuYzElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqeM4888BmvaveugOJqTYWGNm3cTP6qJe444S 7AJaXDnKZlt1cJByB+B83hdGGe2FyRQGGef0DNZhQIfaa41dzZbDWuogZ3mKxyuOhciZSoRoCIM0 jlPh5vqhDmXBPFQ/EedNPRk+tl+mKVz2fHbsI01bWtueV05BvJu330cj0WUCAwEAAaOCAYswggGH MDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDCB kgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwUwdzAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNl Y3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMC AQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCEGA1UdEQQaMBiBFnBldGVyLnJvYmlu c29uQHJzYS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206 ODAvUlNBQ2xhc3MyUGVyc29uYWxDQS5jcmwwHwYDVR0jBBgwFoAUxpPuxqX+41WOz4ojH+6Y3iHy n6cwHQYDVR0OBBYEFGg/pAQlQSo2dvZeyryhS2toL395MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG 9w0BAQUFAAOBgQCY/nGMkd29x8wULeVsTP+emR/XVn+LqcfwzgwpUSKP1FX1WedrHwlNKFaVDjQX FaNETkV4XzMugf4iafsgZUp5DmzIOBB5H5MI1k+CprZ0tjet7gcN0sdCt0fggfw44GZ37rwxzwyt XZrbEePtb8wFYVEobKBD/ZqvghavL93K3DGCA4EwggN9AgEBMIGiMIGMMRowGAYDVQQKExFSU0Eg U2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3Mg MiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEL MAkGA1UEBhMCVVMCEQCxJ73I1MfatgpGI3sXwqGRMAkGBSsOAwIaBQCgggI0MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExODA0NDA1MFowIwYJKoZIhvcNAQkE MRYEFBSxQZqx25aScoyemzyU00DIq3udMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA TA4a793LczoeOI1ZdI5seyjHdi6FGOMKAd2eGL/EC4HdI4sb5avDdoTzykXOZ32qFfJ/8qtI+adg eY9U9g7Zx2m01edfxDomoEzTlMr31QJ1ZJexgdttEI6qu/kak0JmLIDpx1bKOsw7PPAQoOg+NIdT yEDMpDTMKQJhlapDAhIAAAAAAAA= ------=_NextPart_000_102C_01CA685D.1FCAC4B0-- From mrex@sap.com Tue Nov 17 20:48:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FBA13A68AA for ; Tue, 17 Nov 2009 20:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.227, 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 9mq1AtdZpkZa for ; Tue, 17 Nov 2009 20:48:22 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id AB8783A6838 for ; Tue, 17 Nov 2009 20:48:21 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAI4mIY1028214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 05:48:18 +0100 (MET) From: Martin Rex Message-Id: <200911180448.nAI4mIjn019823@fs4113.wdf.sap.corp> To: peter.robinson@rsa.com Date: Wed, 18 Nov 2009 05:48:18 +0100 (MET) In-Reply-To: from "peter.robinson@rsa.com" at Nov 17, 9 11:40:51 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 04:48:23 -0000 I'm sorry for the confusion of the various discussions going on. My idea is to use a bit in the server_version field of the ServerHello PDU to transfer a signal from Server to Client only after the client has indicated to understand this signal. This signal bit is _NOT_ supposed to be used for ClientHello.client_version _NOT_ for record layer version tagging and neither for the version indicate in the TLS session state (because it might confuse existing code), it is purely for transfer over the network. -Martin peter.robinson@rsa.com wrote: > > There have been several posts which have discussed the possibility of re-using > existing fields, rather than use the TLS extension mechanism. Using a field > for anything but its intended purpose is fraught with danger. In particular, > there has been discussion of re-purposing of bits of the TLS Protocol Version. > > Our server code uses the TLS Protocol Version as a numeric value to negotiate > the TLS version. If a client offers TLS 1.0 (3,1) and the server can do TLS > 1.2 (3,3), the server determines that TLS 1.0 (3,1) is less than TLS 1.2 > (3.3), and then chooses TLS 1.0 (3,1). > > If the decision was to signal via the top bit of the protocol version, then an > updated client might offer TLS 1.0 patched (0x83, 1) and a not updated server > can do TLS 1.2 (3,3), the server determines that TLS 1.0patched (0x83,1) is > greater than TLS 1.2 (3,3), and then chooses TLS 1.2 (3,3)! > > > ------------------------------------------------ > Peter Robinson - peter.robinson@rsa.com > Engineering Manager > RSA, The Security Division of EMC - http://www.rsa.com/ > Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, > AUSTRALIA. > Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. > > ------=_NextPart_000_102C_01CA685D.1FCAC4B0 > Content-Type: application/x-pkcs7-signature; > name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="smime.p7s" > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWmzCCAucw > ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l > dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz > IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy > dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa > Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx > FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj > eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v > MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw > gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ > j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK > mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ > M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1 > s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV > 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV > BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs > BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw > MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV > BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y > ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD > gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID > 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i > 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX > i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh > oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j > ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED > MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN > QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO > Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd > oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD > ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT > LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho > dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t > MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5 > IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh > a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA > tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3 > Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/ > eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw > bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv > bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV > HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG > 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys > 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU > vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w > DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL > Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU > BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz > MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy > dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk > MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB > jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5 > /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW > yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG > A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1 > cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB > Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v > Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf > BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y > 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13 > qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt > TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggR+MIID56ADAgECAhEAsSe9 > yNTH2rYKRiN7F8KhkTANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu > Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg > Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT > MB4XDTA5MDcyMTA1MTYxM1oXDTExMDcyMjA1MTYxM1owgekxEzARBgoJkiaJk/IsZAEZFgNjb20x > EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjEMMAoGA1UECxMD > UlNBMRUwEwYDVQQLEwxBc2lhL1BhY2lmaWMxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQF > EwYwNjQ4MTQxFzAVBgoJkiaJk/IsZAEBEwdyb2JpbnAyMRcwFQYDVQQDEw5QZXRlciBSb2JpbnNv > bjElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNvbTCBnzANBgkqhkiG9w0BAQEF > AAOBjQAwgYkCgYEA2CcjIV2QNoJP4YbPejhZX2MSu53/EooTnrkf7M4gsl1DobXkk3CO6kU9bN6O > wwL/o87dQ4y2FHjwkV4WeoodhvZa08q5uX4vZCtB2Hn0OUrbPzyKl7wXSq+yezKCQJBrVCTwWjKK > A6Gqc1VhkqWSBCpUaQ39TsVDxNYCGIn433cCAwEAAaOCAX8wggF7MIGSBgNVHSAEgYowgYcwgYQG > CSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5o > dG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9y > YXRlZCBieSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUF > BwMEMCEGA1UdEQQaMBiBFnBldGVyLnJvYmluc29uQHJzYS5jb20wDgYDVR0PAQH/BAQDAgeAMEYG > A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl > cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQm > 7p962rS9dUpGeQZt+Vi1su6tQTANBgkqhkiG9w0BAQUFAAOBgQCghPP5wxcDJuACPYJ/U1sjhyE4 > gxpGKZNPnnDcjfHo+Cq87cWawpV5Rzpg8KVZc0EoG6BabGNyk+WgZMjCzADpg+appN4cX+DML0ir > 3cBcX8pQTuKw1VRlUjidjkTIl/Z2hrcvgh2lJG+PFV2ogWICzwOj4/zKG4khs9VO5NNPezCCBI4w > ggP3oAMCAQICEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFS > U0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xh > c3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 > czELMAkGA1UEBhMCVVMwHhcNMDkwNzIxMDUxNjE4WhcNMTEwNzIyMDUxMzM2WjCB7TETMBEGCgmS > JomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0 > aW9uMQwwCgYDVQQLEwNSU0ExFTATBgNVBAsTDEFzaWEvUGFjaWZpYzEUMBIGA1UECxMLRW5naW5l > ZXJpbmcxDzANBgNVBAUTBjA2NDgxNDEXMBUGCgmSJomT8ixkAQETB3JvYmlucDIxGzAZBgNVBAMT > ElBldGVyIFJvYmluc29uLUVuYzElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNv > bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqeM4888BmvaveugOJqTYWGNm3cTP6qJe444S > 7AJaXDnKZlt1cJByB+B83hdGGe2FyRQGGef0DNZhQIfaa41dzZbDWuogZ3mKxyuOhciZSoRoCIM0 > jlPh5vqhDmXBPFQ/EedNPRk+tl+mKVz2fHbsI01bWtueV05BvJu330cj0WUCAwEAAaOCAYswggGH > MDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDCB > kgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwUwdzAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNl > Y3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMC > AQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCEGA1UdEQQaMBiBFnBldGVyLnJvYmlu > c29uQHJzYS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206 > ODAvUlNBQ2xhc3MyUGVyc29uYWxDQS5jcmwwHwYDVR0jBBgwFoAUxpPuxqX+41WOz4ojH+6Y3iHy > n6cwHQYDVR0OBBYEFGg/pAQlQSo2dvZeyryhS2toL395MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG > 9w0BAQUFAAOBgQCY/nGMkd29x8wULeVsTP+emR/XVn+LqcfwzgwpUSKP1FX1WedrHwlNKFaVDjQX > FaNETkV4XzMugf4iafsgZUp5DmzIOBB5H5MI1k+CprZ0tjet7gcN0sdCt0fggfw44GZ37rwxzwyt > XZrbEePtb8wFYVEobKBD/ZqvghavL93K3DGCA4EwggN9AgEBMIGiMIGMMRowGAYDVQQKExFSU0Eg > U2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3Mg > MiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEL > MAkGA1UEBhMCVVMCEQCxJ73I1MfatgpGI3sXwqGRMAkGBSsOAwIaBQCgggI0MBgGCSqGSIb3DQEJ > AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExODA0NDA1MFowIwYJKoZIhvcNAQkE > MRYEFBSxQZqx25aScoyemzyU00DIq3udMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI > KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO > AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 > cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl > cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD > VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD > VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS > U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj > aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA > TA4a793LczoeOI1ZdI5seyjHdi6FGOMKAd2eGL/EC4HdI4sb5avDdoTzykXOZ32qFfJ/8qtI+adg > eY9U9g7Zx2m01edfxDomoEzTlMr31QJ1ZJexgdttEI6qu/kak0JmLIDpx1bKOsw7PPAQoOg+NIdT > yEDMpDTMKQJhlapDAhIAAAAAAAA= > > ------=_NextPart_000_102C_01CA685D.1FCAC4B0-- > > --===============2057096671== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --===============2057096671==-- > From djhopwood@googlemail.com Tue Nov 17 21:09:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86143A68B8 for ; Tue, 17 Nov 2009 21:09:56 -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 egOQstqBcODp for ; Tue, 17 Nov 2009 21:09:56 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id B2F543A6768 for ; Tue, 17 Nov 2009 21:09:55 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so55651eya.51 for ; Tue, 17 Nov 2009 21:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=VSBDZfl4nMtENVqjgvq/m68jjkNv11DjoR4NsPfO9vI=; b=nAEUNV4TWazokVery4lsoQ2MjvziK2qMLgnx9pGnXqcSxZzrX1sczj14B9ethbsJnx 1EIvn7k+srpm2sbLfMHH4xVIQz+Fl5tuOY8sI1ivCnUSfu1M3hKfyjMp5JVOtXnSv7Br +tKRBVW71bhoKEgezg12m/iPbspaoXEBnNfcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=kQF5oJnX8BIKs3paBluoySHBPisq6pCihVrcIa4+b3BK5Q8Y1DEXNrMShH7wEtgg0l ojnhEdnzA34t8oUcYR19mJtw85cckipEMx9X1qBV3rdEm7s5qGbCpgZhexDe4u7ogNpl XrGw4U8E1WmlH4tnA+k6owOjpEE0rc6nfOdVk= Received: by 10.213.0.218 with SMTP id 26mr2621446ebc.7.1258520990739; Tue, 17 Nov 2009 21:09:50 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 7sm1002321eyg.9.2009.11.17.21.09.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 21:09:50 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B03816A.5080302@jacaranda.org> Date: Wed, 18 Nov 2009 05:08:58 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4d2fac900911151445v69f84638n11bb9d6525d381ea@mail.gmail.com> <4B012BA3.1040803@opera.com> <66336217-4343-40D2-9E06-6A8C5311686A@apple.com> <88C981CF-1088-4BF8-9767-858362E6D710@mozilla.org> <36424A04-1CA9-44FB-A94D-ABC1F411894F@mozilla.org> <945055E2-FF30-490C-9DB1-DA16C2AED522@apple.com> <2B42655D-2E27-459A-AE5E-8223A8894A38@apple.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8BFF9764F44D5281EFA7A993" Subject: Re: [TLS] Conflicts between W3C specs and ES5? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 05:09:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8BFF9764F44D5281EFA7A993 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brendan Eich wrote: > On Nov 17, 2009, at 6:41 PM, Maciej Stachowiak wrote: >=20 >>>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws [...] >>> >>> What is the rationale for throwing in this last case, rather than >>> using the explicit base object (otherWindow) as |this|? [...] > The standard ECMA-262 semantics want otherWindow -- "bound method" > exceptions prove the rule. There are bound methods in ES implementations? I'm all ears. (One thing I've never understood is why ES implementors add features or exceptional behaviour that users of the language could only find, or even know to look for, by reverse engineering or guesswork. What's the point? Doesn't it take more work to add all this stuff?) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig8BFF9764F44D5281EFA7A993 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksDgXsACgkQWUc8YzyzqAdixgD9ErRe/9V7hr7imN4v97tu+vnl dGzp1mDKPEWY3YDXkJABAJMB5TysEn1nB9YoErX+tMC2tugO0khwBI1qHJrzOX3k =C3E4 -----END PGP SIGNATURE----- --------------enig8BFF9764F44D5281EFA7A993-- From mike-list@pobox.com Tue Nov 17 21:19:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF513A6918 for ; Tue, 17 Nov 2009 21:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 9M5RhCW4oVq8 for ; Tue, 17 Nov 2009 21:19:44 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 0B0E63A6768 for ; Tue, 17 Nov 2009 21:19:43 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 2F6F89F9C2 for ; Wed, 18 Nov 2009 00:19:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=zSlaaNYZr7yi 2MS5UWgp5T4zUYs=; b=TbTqkAQjnXJzv1NooXsImvKtB8urshZqQSZXXc/nFzh/ Ph4r0puoGjLNMmqQUNWmIYFmQ4gM/xGwDZNRHV0enk1rrYqvzYVHAvWgn9YobiQu hTefMU51kMm+LnFpVDT4ZBvxa4Y7k61HfbBFL20MEkw9NckIykvxfTvHDP/G1hI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=NvZjbV cD7pka2BMZrTcNd+Zp2ShOxSI6A1gEa+9GERg1yuRZjpG47tMLXFAr6t5CDrF5Ve C9uCweaNm6OUz3NQzfCHHHoc5vRfP0PlmQORNrkMD7xhE/eKRQF3H4KfN+Dg6yzJ KwT2oemj3x48kZv7qjFVuFfRCf0Aot5TpDruo= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 2C3C89F9C1 for ; Wed, 18 Nov 2009 00:19:42 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id AFB499F9BF for ; Wed, 18 Nov 2009 00:19:41 -0500 (EST) Message-ID: <4B038434.6000005@pobox.com> Date: Tue, 17 Nov 2009 21:20:52 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B036A56.5080801@extendedsubset.com> from "Marsh Ray" at Nov 17, 9 09:30:30 pm <200911180415.nAI4Frd9017599@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: F9F56BDA-D401-11DE-9C0F-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 05:19:45 -0000 peter.robinson@rsa.com wrote: > There have been several posts which have discussed the possibility of re-using > existing fields, rather than use the TLS extension mechanism. Using a field > for anything but its intended purpose is fraught with danger. In particular, > there has been discussion of re-purposing of bits of the TLS Protocol Version. > > Our server code uses the TLS Protocol Version as a numeric value to negotiate > the TLS version. If a client offers TLS 1.0 (3,1) and the server can do TLS > 1.2 (3,3), the server determines that TLS 1.0 (3,1) is less than TLS 1.2 > (3.3), and then chooses TLS 1.0 (3,1). > > If the decision was to signal via the top bit of the protocol version, then an > updated client might offer TLS 1.0 patched (0x83, 1) and a not updated server > can do TLS 1.2 (3,3), the server determines that TLS 1.0patched (0x83,1) is > greater than TLS 1.2 (3,3), and then chooses TLS 1.2 (3,3)! There is a misunderstanding. A client would offer exactly the same version numbers it does today. Where the version number would differ is in the ServerHello.version returned to the client ONLY IF the client sent the "magic" cipher suite indicating it is expecting it. A single bit would be set to indicate that the server is also patched. Martin wants to use the upper bit of the major version number, but I think using the upper bit of the minor version number might be better. Using the minor version would contain this to the 0x03 number space, so the next TLS version can be 4.0 (0x0400), which will be larger than any of these pseudo versions. Further, the version used in the record layer would not change either. This combination of a magic cipher suite and a bit flip in the server version is extremely compatible with all protocol versions including SSLv3, whereas adding extensions to SSLv3 to do RI (even if only that one) could be a hardship for many codebases. In fact this is even compatible with the SSLv2 client hello! (Though I'm sure many of you would consider that a flaw....) Mike From mike-list@pobox.com Tue Nov 17 21:42:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1578F3A6858 for ; Tue, 17 Nov 2009 21:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 XSLIOxpfAaAs for ; Tue, 17 Nov 2009 21:42:09 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 04BB63A67B8 for ; Tue, 17 Nov 2009 21:42:07 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id F13FB809D4 for ; Wed, 18 Nov 2009 00:42:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rLV0tShksC0H FA6a7jKxNsBUZx8=; b=WR/O99t35wqVXhgsZfekOLqzgajEc81+ZO9yu/SjAsz2 SrwKhEDexng1WXaO/HYirqZrpVolSE6K6cSEYH2+L0UOqVGtPXlU/E0h89Jgiee5 tB5fX2zyElCWVxHI1pBSSkT7GeSRr4smIbJXdnV1ZNyJEZjDN3c1djKt3XXLiq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=L2xUsY E8L1e/32GCNIj5YoNS7d6igTm54qUIQuMGiyMw6su5/G3p6Q5KvPFuI43LM4lzoP LRvmWwthwdh9XW8k6+6/WHJSSnjfjkEJTyL5Ssgd/zYjQoZrry4870UA8bOptvMC Sgb/1Rlb1OY6eQEcP36mCXjcpHwK3ooeCMA10= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id ECD86809D3 for ; Wed, 18 Nov 2009 00:42:05 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9C3D1809D2 for ; Wed, 18 Nov 2009 00:42:05 -0500 (EST) Message-ID: <4B038974.9080001@pobox.com> Date: Tue, 17 Nov 2009 21:43:16 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <20091117175000.653E669FBC6@kilo.networkresonance.com> In-Reply-To: <20091117175000.653E669FBC6@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 1AED2604-D405-11DE-AB14-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 05:42:10 -0000 Eric Rescorla wrote: > At Tue, 17 Nov 2009 13:09:24 +0000, > Stephen Farrell wrote: >> Having watched the recent list traffic I find the above convincing. >> I'd love to see a -01 of the above containing the changes EKR has >> mentioned already, and then a WGLC on that. > > I just submitted an -01 version of the draft. This includes the > following changes: > > 1. Clarification of the encoding of the extension per the issue > by Eric Young and Nelson Bolyard. > 2. A bunch of discussion of fallback and the downgrade issue. > 3. A SHOULD level requirement that implementations which simply > reject negotiation still provide an empty extension when > requested by the client, thus signalling that they have > been updated. > 4. A new section 4.3.1 that describes a magic cipher suite > to be used to prevent downgrade attack on implementations > which fall back to no extensions on handshake failure. You forgot to mention: 4.3. SSLv3 SSLv3 does not support extensions and thus it is not possible to securely renegotiate with SSLv3. Deployments wishing to renegotiate securely will need to upgrade to at least TLS 1.0. Is there some secret agenda to kill off SSLv3? What is the point of that? SSLv3 accounts for more than one-in-five connections as reported to this list. There is an alternate proposal that does not have this limitation, and is better in many other respects. Why do you keep pushing this one? Mike From ynir@checkpoint.com Wed Nov 18 00:00:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36ACB3A67EC for ; Wed, 18 Nov 2009 00:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 ogVqXAmRRivh for ; Wed, 18 Nov 2009 00:00:55 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AA56E3A6893 for ; Wed, 18 Nov 2009 00:00:54 -0800 (PST) X-CheckPoint: {4B03A647-3-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4086229C00C; Wed, 18 Nov 2009 10:00:52 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 212F629C002; Wed, 18 Nov 2009 10:00:52 +0200 (IST) X-CheckPoint: {4B03A647-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAI80pGo016216; Wed, 18 Nov 2009 10:00:51 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 18 Nov 2009 10:00:57 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Wed, 18 Nov 2009 10:00:52 +0200 Thread-Topic: [TLS] TLS Protocol Version Thread-Index: AcpoJUKVeu6uvIavRf2TGtuVWQ9NiA== Message-ID: References: <200911180448.nAI4mIjn019823@fs4113.wdf.sap.corp> In-Reply-To: <200911180448.nAI4mIjn019823@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-10-1051177985"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "tls@ietf.org list" Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 08:00:56 -0000 --Apple-Mail-10-1051177985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm very much against that. The protocol version is something everyone looks at: clients, servers = and middleboxes.=20 OTOH the server_random field is treated as random. Yes, even the = timestamp part. I really believe that's the place for the server to signal. As for the client signal, the fake ciphersuite is clean and = not-elegant-but-ok. However, for no reason other than aesthetics, the = client signal should be similar to that of the server. And I'd use two = magic values: - SUPPORT - (client or server) will use new calculation of Finished = message - SAFE - (server only) Renegotiation is disabled. This allows a quicker = fix. Not sure if this is really needed, though. Then you just add the old verify_data to the Finished message, and = there's no need for extensions. On Nov 18, 2009, at 6:48 AM, Martin Rex wrote: > I'm sorry for the confusion of the various discussions going on. >=20 > My idea is to use a bit in the server_version field of the ServerHello = PDU > to transfer a signal from Server to Client only after the client has > indicated to understand this signal. >=20 > This signal bit is _NOT_ supposed to be used for = ClientHello.client_version > _NOT_ for record layer version tagging and neither for the version > indicate in the TLS session state (because it might confuse existing = code), > it is purely for transfer over the network. >=20 > -Martin >=20 > peter.robinson@rsa.com wrote: >>=20 >> There have been several posts which have discussed the possibility of = re-using >> existing fields, rather than use the TLS extension mechanism. Using a = field >> for anything but its intended purpose is fraught with danger. In = particular, >> there has been discussion of re-purposing of bits of the TLS Protocol = Version. >>=20 >> Our server code uses the TLS Protocol Version as a numeric value to = negotiate >> the TLS version. If a client offers TLS 1.0 (3,1) and the server can = do TLS >> 1.2 (3,3), the server determines that TLS 1.0 (3,1) is less than TLS = 1.2 >> (3.3), and then chooses TLS 1.0 (3,1). >>=20 >> If the decision was to signal via the top bit of the protocol = version, then an >> updated client might offer TLS 1.0 patched (0x83, 1) and a not = updated server >> can do TLS 1.2 (3,3), the server determines that TLS 1.0patched = (0x83,1) is >> greater than TLS 1.2 (3,3), and then chooses TLS 1.2 (3,3)! >>=20 >>=20 >> ------------------------------------------------ >> Peter Robinson - peter.robinson@rsa.com >> Engineering Manager >> RSA, The Security Division of EMC - http://www.rsa.com/ >> Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland = 4000, >> AUSTRALIA. >> Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 = 4400. --Apple-Mail-10-1051177985 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExODA4 MDA1MlowIwYJKoZIhvcNAQkEMRYEFCzSD+wrVFeiDuuq4h440/EWJWO3MIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQB9fkANt0QP hgv/E3eJqtCGO/wKVA4KxnyfqxvWMtP4/Uikn72LmG/0sk7cjT3BvYVesYTQGcB01qNk8BlWO//b VqUBROl1jxDeBcllkNr4rgLcm/Cd/BAKUzm00WtrdDbyoLPG254EQR5r6d3n9ziAfIerLHCuAVaD qsLjo5IzucSvPJxRFqdVz9AYAl41J+onDpQ1+drgKPheP8rhLkSPDLC+h/gtf6finKowHAFbZKb7 FzdjoKwxEFJk27XZ6iegKG/xIJAMgSI+YVX5EZEx8xa96vyMDXuLzD4FgMqu6nMCkqt5n2fKeD7I S9Zi/ylzG+qBm7JEbHoybklvCikIAAAAAAAA --Apple-Mail-10-1051177985-- From ekr@networkresonance.com Wed Nov 18 00:02:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC703A6858 for ; Wed, 18 Nov 2009 00:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGDIw9o+66Cw for ; Wed, 18 Nov 2009 00:02:19 -0800 (PST) Received: from mail02.sov.host.iqunity.net (iqsexf02.sov.host.iqunity.net [84.233.227.93]) by core3.amsl.com (Postfix) with ESMTP id 7A16B3A63EB for ; Wed, 18 Nov 2009 00:02:19 -0800 (PST) Received: from kilo.networkresonance.com ([10.129.250.199]) by mail02.sov.host.iqunity.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 07:55:10 +0000 Received: from kilo.networkresonance.com ([10.64.254.35] helo=kilo.networkresonance.com) by ASSP.nospam; 18 Nov 2009 08:02:04 +0000 Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9D4FB69FC85; Wed, 18 Nov 2009 08:03:33 +0000 (GMT) Date: Wed, 18 Nov 2009 08:03:33 +0000 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B038974.9080001@pobox.com> References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <20091117175000.653E669FBC6@kilo.networkresonance.com> <4B038974.9080001@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091118080333.9D4FB69FC85@kilo.networkresonance.com> X-Assp-Delay: not delayed (auto accepted); 18 Nov 2009 08:02:04 +0000 X-Assp-Received-DNSBL: pass X-Assp-Received-URIBL: pass X-Assp-Spam-Prob: 0.00000 X-Assp-Envelope-From: ekr@networkresonance.com X-Assp-Intended-For: tls@ietf.org X-OriginalArrivalTime: 18 Nov 2009 07:55:20.0481 (UTC) FILETIME=[79C90910:01CA6824] Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 08:02:20 -0000 At Tue, 17 Nov 2009 21:43:16 -0800, Michael D'Errico wrote: > You forgot to mention: > > 4.3. SSLv3 > > SSLv3 does not support extensions and thus it is not possible to > securely renegotiate with SSLv3. Deployments wishing to renegotiate > securely will need to upgrade to at least TLS 1.0. > > Is there some secret agenda to kill off SSLv3? What is the point > of that? Well, I don't think it's a secret that many feel that it would be good for people to upgrade from SSLv3 to TLS. TLS includes a number of useful security fixes and extended functionality. So, it's not clear it's great to go out of our way to preserve its use indefinitely. With that said, I think that the quoted sentence is probably slightly too strong. There's no reason why extensions cannot be used with SSLv3, it's just that the IETF has no change control on SSLv3 and so it's kind of a matter of extrapolating 4366 to apply to the SSLv3 drafts. This is straightforward but undocumented. > SSLv3 accounts for more than one-in-five connections as > reported to this list. Well, I've seen this claimed, but I haven't seen a citation for where the data comes from. I'd be interested in seeing such a cite. The data I've seen (and posted) suggests that servers support TLS very widely, and certainly every piece of SSL/TLS-based software built on any even remotely modern stack includes support for TLS, whatever it chooses to negotiate. > There is an alternate proposal that does not > have this limitation, and is better in many other respects. Why do > you keep pushing this one? Because I feel that those other proposals are inferior in many other respects? I'm not sure why this is so hard for you to understand. -Ekr From rdugal@certicom.com Wed Nov 18 03:21:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66473A6B0A for ; Wed, 18 Nov 2009 03:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 k-8JuzvULc4h for ; Wed, 18 Nov 2009 03:21:21 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 48BD63A6B09 for ; Wed, 18 Nov 2009 03:21:21 -0800 (PST) X-AuditID: 0a666446-b7b5eae0000003bc-ce-4b03d8ae65ef Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 8E.B9.00956.EA8D30B4; Wed, 18 Nov 2009 06:21:18 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 06:21:18 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Wed, 18 Nov 2009 06:18:47 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC40251FFC1@XCH57YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS Protocol Version Thread-Index: AcpoJUKVeu6uvIavRf2TGtuVWQ9NiAAG01SQ References: <200911180448.nAI4mIjn019823@fs4113.wdf.sap.corp> From: "Robert Dugal" To: X-OriginalArrivalTime: 18 Nov 2009 11:21:18.0356 (UTC) FILETIME=[3FA71D40:01CA6841] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:21:22 -0000 Me too. I am against doing anything that involves modifying the protocol ver= sion. -- Robert Dugal Senior Software Developer Certicom Corp. A Subsidiary of Research In Motion rdugal@certicom.com direct=A0=A0=A0=A0=A0=A0=A0=A0905.501.3848 fax=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0905.507.4230 www.certicom.com -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Yoav N= ir Sent: Wednesday, November 18, 2009 3:01 AM To: mrex@sap.com Cc: tls@ietf.org list Subject: Re: [TLS] TLS Protocol Version I'm very much against that. The protocol version is something everyone looks at: clients, servers and mi= ddleboxes. OTOH the server_random field is treated as random. Yes, even the timestamp p= art. I really believe that's the place for the server to signal. As for the client signal, the fake ciphersuite is clean and not-elegant-but-= ok. However, for no reason other than aesthetics, the client signal should= be similar to that of the server. And I'd use two magic values: - SUPPORT - (client or server) will use new calculation of Finished message - SAFE - (server only) Renegotiation is disabled. This allows a quicker fix= . Not sure if this is really needed, though. Then you just add the old verify_data to the Finished message, and there's n= o need for extensions. On Nov 18, 2009, at 6:48 AM, Martin Rex wrote: > I'm sorry for the confusion of the various discussions going on. > > My idea is to use a bit in the server_version field of the ServerHello > PDU to transfer a signal from Server to Client only after the client > has indicated to understand this signal. > > This signal bit is _NOT_ supposed to be used for > ClientHello.client_version _NOT_ for record layer version tagging and > neither for the version indicate in the TLS session state (because it > might confuse existing code), it is purely for transfer over the network. > > -Martin > > peter.robinson@rsa.com wrote: >> >> There have been several posts which have discussed the possibility of >> re-using existing fields, rather than use the TLS extension >> mechanism. Using a field for anything but its intended purpose is >> fraught with danger. In particular, there has been discussion of re-purpo= sing of bits of the TLS Protocol Version. >> >> Our server code uses the TLS Protocol Version as a numeric value to >> negotiate the TLS version. If a client offers TLS 1.0 (3,1) and the >> server can do TLS >> 1.2 (3,3), the server determines that TLS 1.0 (3,1) is less than TLS >> 1.2 (3.3), and then chooses TLS 1.0 (3,1). >> >> If the decision was to signal via the top bit of the protocol >> version, then an updated client might offer TLS 1.0 patched (0x83, 1) >> and a not updated server can do TLS 1.2 (3,3), the server determines >> that TLS 1.0patched (0x83,1) is greater than TLS 1.2 (3,3), and then choo= ses TLS 1.2 (3,3)! >> >> >> ------------------------------------------------ >> Peter Robinson - peter.robinson@rsa.com Engineering Manager RSA, The >> Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront >> Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA. >> Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From rdugal@certicom.com Wed Nov 18 03:32:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F213A6AD5 for ; Wed, 18 Nov 2009 03:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 nLsW1VN3DGiI for ; Wed, 18 Nov 2009 03:32:24 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 30BE43A68CB for ; Wed, 18 Nov 2009 03:32:24 -0800 (PST) X-AuditID: 0a401fcb-b7b71ae000002562-89-4b03db45bb76 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 42.33.09570.54BD30B4; Wed, 18 Nov 2009 06:32:21 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 06:32:21 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Wed, 18 Nov 2009 06:31:28 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC40251FFC6@XCH57YKF.rim.net> In-Reply-To: <4B032EFC.6050707@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Implementation Experience Thread-Index: Acpn2/4aNMbZNBTxT4m7IjonWBK20AAZPlfQ References: <4B032EFC.6050707@pobox.com> From: "Robert Dugal" To: X-OriginalArrivalTime: 18 Nov 2009 11:32:21.0015 (UTC) FILETIME=[CAA0DA70:01CA6842] X-Brightmail-Tracker: AAAAAgAAAZERyCBQ Subject: Re: [TLS] Implementation Experience X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:32:25 -0000 Other implementors may not experience the same code size cost as your findin= gs. Our product already implements several TLS extensions and has all the framew= ork in place to add more. Adding the extension support itself is trivial. Tieing renegotiation to the= extension is trivial too. We also have a framework for testing extensions. I suspect the most code I would have to write is test and sample code. -- Robert Dugal Senior Software Developer Certicom Corp. A Subsidiary of Research In Motion rdugal@certicom.com direct=A0=A0=A0=A0=A0=A0=A0=A0905.501.3848 fax=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0905.507.4230 www.certicom.com -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Michae= l D'Errico Sent: Tuesday, November 17, 2009 6:17 PM To: tls@ietf.org Subject: [TLS] Implementation Experience I have some hard numbers to share regarding implementation of the RI extension and the alternate proposal given below. I initially implemented the RI extension in my code and based on the CVS logs, the net addition of code was 248 lines of C++. Just this morning I ripped out the RI extension and instead implemented the alternate proposal. Based on the CVS logs there was a net decrease of 91 lines of code. That means RI requires 58% MORE CODE in a codebase that already fully supports TLS extensions. In addition, RI practically requires implementing fallback code, which I did not add, so I would bet RI requires at least double the amount of code as this alternate proposal, and possibly a lot more given the myriad possible fallback scenarios. I will be installing this change on my test server shortly for anyone to test against. Mike ----------------------------------------------------------- Alternate proposal to RI: - Client includes a special cipher suite as the first in its cipher suite list. The value chosen for testing: 0xBFFF (the last of the "Standards Action" cipher suites -- I'm pretty sure I've seen 0xFEFF used in the wild) - Upon seeing this marker, the server does the following: a) sets the high bit of the low byte of the version returned in ServerHello -- this indicates to the client that the server recognized the special cipher suite -- the record layer version uses the normal version number without the high bit set; Examples: SSLv3: 0x0380 TLS 1.0: 0x0381 TLS 1.1: 0x0382 TLS 1.2: 0x0383 b) adds to the Handshake Hash the PreviousVerifyData structure (see below) immediately following ServerHello; only the PreviousVerifyData is added, it is not wrapped to look like a handshake message with a type and length. - Upon noticing the high bit of the low byte of the server's version being set, the client does the following: a) resets the high bit of the low byte of the version to be used for the record layer version b) adds to the Handshake Hash the PreviousVerifyData structure immediately following ServerHello A server would obviously not renegotiate if the magic cipher suite is not present in the renegotiation ClientHello. If it is present but is actually a proxied initial handshake through a MITM, the PreviousVerifyData used by client and server will be different and thus the handshake will fail and the attack prevented. PreviousVerifyData structure: struct { opaque previous_client_verify_data<0..255>; opaque previous_server_verify_data<0..255>; } PreviousVerifyData; The PreviousVerifyData on the initial handshake would be just two zero bytes, one for each of the lengths of the opaque vectors. When renegotiating, it will look like: 0x0C [12 client verify data bytes] 0x0C [12 server bytes] for a total of 26 bytes added to the handshake hash. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From uri@ll.mit.edu Wed Nov 18 04:13:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A962A28C0D0 for ; Wed, 18 Nov 2009 04:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqJfDfiUlrLv for ; Wed, 18 Nov 2009 04:13:51 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id B5E783A693A for ; Wed, 18 Nov 2009 04:13:51 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAICDjjl011095 for ; Wed, 18 Nov 2009 07:13:45 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAOJaafk; Wed Nov 18 07:03:05 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 18 Nov 2009 07:03:04 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Wed, 18 Nov 2009 07:02:58 -0500 Thread-Topic: [TLS] TLS Protocol Version Thread-Index: AcpoJUKVeu6uvIavRf2TGtuVWQ9NiAAG01SQAAGhX9g= Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3E3@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:13:53 -0000 QWZ0ZXIgZm9sbG93aW5nIHRoaXMgZGlzY3Vzc2lvbiBmb3IgYSB3aGlsZSwgSSBjYW4gc2F5IHRo YXQgSSB0b28gYW0gYWdhaW5zdCBmb29saW5nIGFyb3VuZCB3aXRoIHByb3RvY29sIHZlcnNpb24g bnVtYmVyIChvciB3aXRoIHJlLXB1cnBvc2luZyBhbiBleGlzdGluZyBmaWVsZCkuIEEgY2xlYW4g ZXh0ZW5zaW9uLWJhc2VkIHNvbHV0aW9uIGlzIHdoYXQncyBuZWVkZWQuIEFuZCBpZiBTU0x2MyBj YW4ndC93b24ndCBzdXBwb3J0IGl0IC0gc28gYmUgaXQuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KRnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYu b3JnPg0KVG86IHRsc0BpZXRmLm9yZyA8dGxzQGlldGYub3JnPg0KU2VudDogV2VkIE5vdiAxOCAw NjoxODo0NyAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBUTFMgUHJvdG9jb2wgVmVyc2lvbg0KDQpN ZSB0b28uIEkgYW0gYWdhaW5zdCBkb2luZyBhbnl0aGluZyB0aGF0IGludm9sdmVzIG1vZGlmeWlu ZyB0aGUgcHJvdG9jb2wgdmVyc2lvbi4gDQoNCi0tIA0KUm9iZXJ0IER1Z2FsCQlTZW5pb3IgU29m dHdhcmUgRGV2ZWxvcGVyDQpDZXJ0aWNvbSBDb3JwLgkJQSBTdWJzaWRpYXJ5IG9mIFJlc2VhcmNo IEluIE1vdGlvbiANCnJkdWdhbEBjZXJ0aWNvbS5jb20NCmRpcmVjdMKgwqDCoMKgwqDCoMKgwqA5 MDUuNTAxLjM4NDgNCmZheMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqA5MDUuNTA3LjQyMzANCnd3 dy5jZXJ0aWNvbS5jb20NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdGxz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFlvYXYgTmlyDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE4LCAyMDA5IDM6MDEgQU0N ClRvOiBtcmV4QHNhcC5jb20NCkNjOiB0bHNAaWV0Zi5vcmcgbGlzdA0KU3ViamVjdDogUmU6IFtU TFNdIFRMUyBQcm90b2NvbCBWZXJzaW9uDQoNCkknbSB2ZXJ5IG11Y2ggYWdhaW5zdCB0aGF0Lg0K DQpUaGUgcHJvdG9jb2wgdmVyc2lvbiBpcyBzb21ldGhpbmcgZXZlcnlvbmUgbG9va3MgYXQ6IGNs aWVudHMsIHNlcnZlcnMgYW5kIG1pZGRsZWJveGVzLiANCg0KT1RPSCB0aGUgc2VydmVyX3JhbmRv bSBmaWVsZCBpcyB0cmVhdGVkIGFzIHJhbmRvbS4gWWVzLCBldmVuIHRoZSB0aW1lc3RhbXAgcGFy dC4NCg0KSSByZWFsbHkgYmVsaWV2ZSB0aGF0J3MgdGhlIHBsYWNlIGZvciB0aGUgc2VydmVyIHRv IHNpZ25hbC4NCg0KQXMgZm9yIHRoZSBjbGllbnQgc2lnbmFsLCB0aGUgZmFrZSBjaXBoZXJzdWl0 ZSBpcyBjbGVhbiBhbmQgbm90LWVsZWdhbnQtYnV0LW9rLiAgSG93ZXZlciwgZm9yIG5vIHJlYXNv biBvdGhlciB0aGFuIGFlc3RoZXRpY3MsIHRoZSBjbGllbnQgc2lnbmFsIHNob3VsZCBiZSBzaW1p bGFyIHRvIHRoYXQgb2YgdGhlIHNlcnZlci4gQW5kIEknZCB1c2UgdHdvIG1hZ2ljIHZhbHVlczoN CiAtIFNVUFBPUlQgLSAoY2xpZW50IG9yIHNlcnZlcikgd2lsbCB1c2UgbmV3IGNhbGN1bGF0aW9u IG9mIEZpbmlzaGVkIG1lc3NhZ2UNCiAtIFNBRkUgLSAoc2VydmVyIG9ubHkpIFJlbmVnb3RpYXRp b24gaXMgZGlzYWJsZWQuIFRoaXMgYWxsb3dzIGEgcXVpY2tlciBmaXguIE5vdCBzdXJlIGlmIHRo aXMgaXMgcmVhbGx5IG5lZWRlZCwgdGhvdWdoLg0KDQpUaGVuIHlvdSBqdXN0IGFkZCB0aGUgb2xk IHZlcmlmeV9kYXRhIHRvIHRoZSBGaW5pc2hlZCBtZXNzYWdlLCBhbmQgdGhlcmUncyBubyBuZWVk IGZvciBleHRlbnNpb25zLg0KDQoNCk9uIE5vdiAxOCwgMjAwOSwgYXQgNjo0OCBBTSwgTWFydGlu IFJleCB3cm90ZToNCg0KPiBJJ20gc29ycnkgZm9yIHRoZSBjb25mdXNpb24gb2YgdGhlIHZhcmlv dXMgZGlzY3Vzc2lvbnMgZ29pbmcgb24uDQo+IA0KPiBNeSBpZGVhIGlzIHRvIHVzZSBhIGJpdCBp biB0aGUgc2VydmVyX3ZlcnNpb24gZmllbGQgb2YgdGhlIFNlcnZlckhlbGxvIA0KPiBQRFUgdG8g dHJhbnNmZXIgYSBzaWduYWwgZnJvbSBTZXJ2ZXIgdG8gQ2xpZW50IG9ubHkgYWZ0ZXIgdGhlIGNs aWVudCANCj4gaGFzIGluZGljYXRlZCB0byB1bmRlcnN0YW5kIHRoaXMgc2lnbmFsLg0KPiANCj4g VGhpcyBzaWduYWwgYml0IGlzIF9OT1RfIHN1cHBvc2VkIHRvIGJlIHVzZWQgZm9yIA0KPiBDbGll bnRIZWxsby5jbGllbnRfdmVyc2lvbiBfTk9UXyBmb3IgcmVjb3JkIGxheWVyIHZlcnNpb24gdGFn Z2luZyBhbmQgDQo+IG5laXRoZXIgZm9yIHRoZSB2ZXJzaW9uIGluZGljYXRlIGluIHRoZSBUTFMg c2Vzc2lvbiBzdGF0ZSAoYmVjYXVzZSBpdCANCj4gbWlnaHQgY29uZnVzZSBleGlzdGluZyBjb2Rl KSwgaXQgaXMgcHVyZWx5IGZvciB0cmFuc2ZlciBvdmVyIHRoZSBuZXR3b3JrLg0KPiANCj4gLU1h cnRpbg0KPiANCj4gcGV0ZXIucm9iaW5zb25AcnNhLmNvbSB3cm90ZToNCj4+IA0KPj4gVGhlcmUg aGF2ZSBiZWVuIHNldmVyYWwgcG9zdHMgd2hpY2ggaGF2ZSBkaXNjdXNzZWQgdGhlIHBvc3NpYmls aXR5IG9mIA0KPj4gcmUtdXNpbmcgZXhpc3RpbmcgZmllbGRzLCByYXRoZXIgdGhhbiB1c2UgdGhl IFRMUyBleHRlbnNpb24gDQo+PiBtZWNoYW5pc20uIFVzaW5nIGEgZmllbGQgZm9yIGFueXRoaW5n IGJ1dCBpdHMgaW50ZW5kZWQgcHVycG9zZSBpcyANCj4+IGZyYXVnaHQgd2l0aCBkYW5nZXIuIElu IHBhcnRpY3VsYXIsIHRoZXJlIGhhcyBiZWVuIGRpc2N1c3Npb24gb2YgcmUtcHVycG9zaW5nIG9m IGJpdHMgb2YgdGhlIFRMUyBQcm90b2NvbCBWZXJzaW9uLg0KPj4gDQo+PiBPdXIgc2VydmVyIGNv ZGUgdXNlcyB0aGUgVExTIFByb3RvY29sIFZlcnNpb24gYXMgYSBudW1lcmljIHZhbHVlIHRvIA0K Pj4gbmVnb3RpYXRlIHRoZSBUTFMgdmVyc2lvbi4gSWYgYSBjbGllbnQgb2ZmZXJzIFRMUyAxLjAg KDMsMSkgYW5kIHRoZSANCj4+IHNlcnZlciBjYW4gZG8gVExTDQo+PiAxLjIgKDMsMyksIHRoZSBz ZXJ2ZXIgZGV0ZXJtaW5lcyB0aGF0IFRMUyAxLjAgKDMsMSkgaXMgbGVzcyB0aGFuIFRMUyANCj4+ IDEuMiAoMy4zKSwgYW5kIHRoZW4gY2hvb3NlcyBUTFMgMS4wICgzLDEpLg0KPj4gDQo+PiBJZiB0 aGUgZGVjaXNpb24gd2FzIHRvIHNpZ25hbCB2aWEgdGhlIHRvcCBiaXQgb2YgdGhlIHByb3RvY29s IA0KPj4gdmVyc2lvbiwgdGhlbiBhbiB1cGRhdGVkIGNsaWVudCBtaWdodCBvZmZlciBUTFMgMS4w IHBhdGNoZWQgKDB4ODMsIDEpIA0KPj4gYW5kIGEgbm90IHVwZGF0ZWQgc2VydmVyIGNhbiBkbyBU TFMgMS4yICgzLDMpLCB0aGUgc2VydmVyIGRldGVybWluZXMgDQo+PiB0aGF0IFRMUyAxLjBwYXRj aGVkICgweDgzLDEpIGlzIGdyZWF0ZXIgdGhhbiBUTFMgMS4yICgzLDMpLCBhbmQgdGhlbiBjaG9v c2VzIFRMUyAxLjIgKDMsMykhDQo+PiANCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBQZXRlciBSb2JpbnNvbiAtIHBldGVyLnJvYmlu c29uQHJzYS5jb20gRW5naW5lZXJpbmcgTWFuYWdlciBSU0EsIFRoZSANCj4+IFNlY3VyaXR5IERp dmlzaW9uIG9mIEVNQyAtIGh0dHA6Ly93d3cucnNhLmNvbS8gTGV2ZWwgMzIsIFdhdGVyZnJvbnQg DQo+PiBQbGFjZSwgMSBFYWdsZSBTdHJlZXQsIEJyaXNiYW5lLCBRdWVlbnNsYW5kIDQwMDAsIEFV U1RSQUxJQS4NCj4+IFBob25lOiArNjEgNyAzMjI3IDQ0MjcsIE1vYmlsZTogKzYxIDQwNyA5NjIg MTUwLCBGYXg6ICs2MSA3IDMyMjcgNDQwMC4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNt aXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBw cm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2 aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9m IHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lw aWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkg dW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExT IG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Rscw0K From rdugal@certicom.com Wed Nov 18 04:48:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D023A6A3F for ; Wed, 18 Nov 2009 04:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 xpndSnXxx3eI for ; Wed, 18 Nov 2009 04:48:41 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 3D08E3A6A48 for ; Wed, 18 Nov 2009 04:48:39 -0800 (PST) X-AuditID: 0a666446-b7b5eae0000003bc-d3-4b03ed242355 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 23.9C.00956.42DE30B4; Wed, 18 Nov 2009 07:48:36 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 07:48:36 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Wed, 18 Nov 2009 07:39:20 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC40251FFD4@XCH57YKF.rim.net> In-Reply-To: <20091117175000.653E669FBC6@kilo.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpnrjHa7BtLzM/dQ0S4W6fTw5BNeQAnTqLg References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp><089F31C221374096B0FE619F@446E7922C82D299DB29D899F><4B02A084.9030903@cs.tcd.ie> <20091117175000.653E669FBC6@kilo.networkresonance.com> From: "Robert Dugal" To: "Eric Rescorla" X-OriginalArrivalTime: 18 Nov 2009 12:48:36.0277 (UTC) FILETIME=[71B26E50:01CA684D] X-Brightmail-Tracker: AAAAAgAAAZERyCBQ Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:48:42 -0000 I noticed you said this in the jabber log http://www.ietf.org/jabber/logs/tl= s/2009-11-12.txt [06:31:06] It occurred to me the other day that there is a special cas= e where hte server does not need to refuse renegotiation: when the client ha= s sent no data yet. [06:31:20] This would allow step-up/SGC to continue to work 9assuming= we cared it) Our products do support step-up/SGC and some customers may still be using it= , or at least have servers with SGC certificates. Since there is no vulnerability is this special case, should some note be ad= ded to the draft? -- Robert Dugal Senior Software Developer Certicom Corp. A Subsidiary of Research In Motion rdugal@certicom.com direct=A0=A0=A0=A0=A0=A0=A0=A0905.501.3848 fax=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0905.507.4230 www.certicom.com -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Eric R= escorla Sent: Tuesday, November 17, 2009 12:50 PM To: Stephen Farrell Cc: Chris Newman; tls@ietf.org Subject: Re: [TLS] simplistic renego protection At Tue, 17 Nov 2009 13:09:24 +0000, Stephen Farrell wrote: > Having watched the recent list traffic I find the above convincing. > I'd love to see a -01 of the above containing the changes EKR has > mentioned already, and then a WGLC on that. I just submitted an -01 version of the draft. This includes the following changes: 1. Clarification of the encoding of the extension per the issue by Eric Young and Nelson Bolyard. 2. A bunch of discussion of fallback and the downgrade issue. 3. A SHOULD level requirement that implementations which simply reject negotiation still provide an empty extension when requested by the client, thus signalling that they have been updated. 4. A new section 4.3.1 that describes a magic cipher suite to be used to prevent downgrade attack on implementations which fall back to no extensions on handshake failure. I've left point (4) as an OPEN ISSUE because it wasn't clear to me what the WG feeling was. My general feeling is that it's not necesary: SSLv3 servers which upgrade to fix this issue by refusing renegotiation can easily arrange to simply ignore the extension, at which point no downgrade attack is possible. Servers which don't do even this can be presumed to be vulnerable and it doesn't seem that bad to simply fail in this small number of cases. That said, I don't have a problem with this feature f the WG wants to since it's not being used by negotiation but merely as a failsafe, and I thought it was important to get a concrete proposal for this mechanism on the table. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From Pasi.Eronen@nokia.com Wed Nov 18 05:31:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 320473A6956 for ; Wed, 18 Nov 2009 05:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 5rt-1nGmlNQT for ; Wed, 18 Nov 2009 05:31:37 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 521C83A67AC for ; Wed, 18 Nov 2009 05:31:37 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAIDVEkX013273; Wed, 18 Nov 2009 07:31:34 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 15:31:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 15:31:33 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 18 Nov 2009 14:31:31 +0100 From: To: , Date: Wed, 18 Nov 2009 14:31:31 +0100 Thread-Topic: [TLS] user requirements for TLS fix Thread-Index: AcpnNWWwQ8ERQAPQRJKofF7Scwe5jgBHG01w Message-ID: <808FD6E27AD4884E94820BC333B2DB774F30FE105B@NOK-EUMSG-01.mgdnok.nokia.com> References: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> In-Reply-To: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2009 13:31:33.0213 (UTC) FILETIME=[71ABA8D0:01CA6853] X-Nokia-AV: Clean Subject: Re: [TLS] user requirements for TLS fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 13:31:38 -0000 Chris Newman wrote: > As a power user, I want two settings for my all my TLS clients ASAP: >=20 > 1. treat unpatched servers as if SSL/TLS was not being used with > respect to security indicators in the UI; but otherwise continue > with connection. >=20 > 2. Warn when contacting an unpatched server giving me the option to > abort the transaction (and even better if it won't bother me for a > month or so if I choose to continue). >=20 > I will use option 1 most of the time initially and will switch to > option 2 when the time is right (maybe a year or so?). This seems to be confusing "unpatched" (*) with "vulnerable". But servers that never allowed renegotiation to begin with are not vulnerable, and many others can just disable renegotiation (without implementing anything else). These servers won't have any need to patch, and will be around "unpatched" much longer than a year=20 from now. (*) I'm guessing here "unpatched" means "do not implement some kind of signalled change to TLS protocol (either a TLS extension, magic cipher suite, alert message, change in Finished message calculation, or something else). It seems actually probing whether the server=20 is vulnerable (i.e., supports "old style" renegotiation without=20 any of the proposed fixes) isn't very reliable (or otherwise good idea). =20 Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Wed Nov 18 05:40:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F4728C0E4 for ; Wed, 18 Nov 2009 05:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.324 X-Spam-Level: X-Spam-Status: No, score=-5.324 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, MANGLED_TOOL=2.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 ARBXkszwm0QM for ; Wed, 18 Nov 2009 05:40:37 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9C2E728C0E1 for ; Wed, 18 Nov 2009 05:40:36 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAIDeMiw008391; Wed, 18 Nov 2009 15:40:30 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 15:40:25 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 15:40:20 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 15:40:16 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 18 Nov 2009 14:40:14 +0100 From: To: , Date: Wed, 18 Nov 2009 14:40:14 +0100 Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpnQz+zDD6oQxHgQOC8LRMIK3HaegBEOl7g Message-ID: <808FD6E27AD4884E94820BC333B2DB774F30FE106F@NOK-EUMSG-01.mgdnok.nokia.com> References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022EBB.5030108@pobox.com> In-Reply-To: <4B022EBB.5030108@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2009 13:40:16.0480 (UTC) FILETIME=[A98FDE00:01CA6854] X-Nokia-AV: Clean Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 13:40:38 -0000 It seems many of the drawbacks of tls-renegotiation-00 you mention=20 are in fact addressed (to some degree) in version -01? (mainly by including the "magic cipher suite") Compared to -01, what do you think the main differences are? Best regards, Pasi (not wearing any hats) > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Michael D'Errico > Sent: 17 November, 2009 07:04 > To: tls@ietf.org > Subject: Re: [TLS] simplistic renego protection >=20 > > If you want your alternative proposal to be considered, submit an > > Internet draft and get some running code and feedback from > > implementations showing your proposal would deploy protection to more > > users than draft-rescorla-tls-renegotiation-00. Then you may sway > > people to your viewpoint. >=20 > Here is how draft-rescorla-tls-renegotiation-00 fails to protect the > most people: >=20 > - there are so many interoperability problems with TLS extensions > that even the author of the draft suggests that a "lenient"[*] > client not send the extension on its initial connection >=20 > - there will be a transition period where some servers absolutely > need to continue allowing unpatched clients to perform the current > vulnerable renegotiation. >=20 > - a lenient client's handshake without the RI extension looks just > like an unpatched client that these unfortunate servers need to > continue supporting >=20 > - a man-in-the-middle can take advantage of these three points to > victimize a patched client talking to a patched server! >=20 > Just today many of us have converged on an alternate solution that does > not have this serious problem. Instead of using extensions with all > the myriad problems, the only bits-on-the-wire change is to include a > single special cipher suite that signals to the server that the client > wishes to use a new calculation of the Finished messages that includes > the verify_data from the previous handshake. I suggested that an alert > message could be used for the server to acknowledge back to the client. >=20 > This uses only features that are present in SSLv3, so it is much more > likely to be implemented quickly and correctly, and it does not require > implementations to add any code for extension processing if they don't > already support extensions. It also protects the lenient client and > unfortunate servers above since there is no reason not to include the > magic cipher suite in ALL handshakes. >=20 > Here is a pointer to a summary of the proposal: >=20 > http://www.ietf.org/mail-archive/web/tls/current/msg04393.html >=20 > I am not a spec. writer, so someone else should write it up. If it is > adopted I will implement it in my test server in short order for anyone > to test against. >=20 > Mike >=20 >=20 > [*] a lenient client is one that would connect to any server regardless > of whether it is patched or not. Since there is a not-insignificant > chance that a server will barf on the use of extensions, and the > lenient > client wouldn't abort the handshake even if the extension is not > returned by the server, it is less painful to just do what's always > been done. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Wed Nov 18 06:25:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90723A6AA0 for ; Wed, 18 Nov 2009 06:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.029 X-Spam-Level: X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=0.220, 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 IOIyzIc5PZ0y for ; Wed, 18 Nov 2009 06:25:41 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 61E353A6A8D for ; Wed, 18 Nov 2009 06:25:40 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAIEPbl7027901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 15:25:37 +0100 (MET) From: Martin Rex Message-Id: <200911181423.nAIENne8023747@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 18 Nov 2009 15:23:49 +0100 (MET) In-Reply-To: <4B038434.6000005@pobox.com> from "Michael D'Errico" at Nov 17, 9 09:20:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:25:42 -0000 If you are referring to the SSLv2 backwards-compatibility option, that seems to be actually still used in Firefox 3.5 in the automatic reconnect fallback should the server choke on TLS extensions. And yes, *I* think it is a feature to even support this case, because we're suggesting to quickly fix an urgent security problem and _NOW_ is not the time to unnecessarily killing existing usage scenarios, no matter how outdated they might look. Requiring them to change that before shipping the patch would be an unecessary burden, unnecessary risk and it could delay the shipment of the patch. If we want vendors and suppliers to ship this fix fast, then we ought to try hard to _not_ break things, in particular, not break things unnecessarily. If, on the other hand, the TLS WG prefers the attitude: "we know that using TLS extensions for the fix will break a number of existing usage scenarios, but we think these usage scenarios ought to be abandoned anyway, so we simply don't care." then this will significantly slow down the deployment of patches, since everyone will want to carefully test the existing usage scenarios before risking to deploy the patch. Improving interoperability with and tolerance for TLS extensions could have been a working group item three years ago, when the issue was brought to the attention of the TLS WG here http://tools.ietf.org/html/draft-pettersen-tls-interop-experience-00 when there was no time constraint on making TLS extensions usable on he Internet. -Martin Michael D'Errico wrote: > > There is a misunderstanding. A client would offer exactly the same version > numbers it does today. Where the version number would differ is in the > ServerHello.version returned to the client ONLY IF the client sent the > "magic" cipher suite indicating it is expecting it. > > A single bit would be set to indicate that the server is also patched. > Martin wants to use the upper bit of the major version number, but I think > using the upper bit of the minor version number might be better. Using the > minor version would contain this to the 0x03 number space, so the next TLS > version can be 4.0 (0x0400), which will be larger than any of these pseudo > versions. > > Further, the version used in the record layer would not change either. > > This combination of a magic cipher suite and a bit flip in the server version > is extremely compatible with all protocol versions including SSLv3, whereas > adding extensions to SSLv3 to do RI (even if only that one) could be a > hardship for many codebases. In fact this is even compatible with the > SSLv2 client hello! (Though I'm sure many of you would consider that a > flaw....) From mrex@sap.com Wed Nov 18 06:36:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6493A6A48 for ; Wed, 18 Nov 2009 06:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.036 X-Spam-Level: X-Spam-Status: No, score=-6.036 tagged_above=-999 required=5 tests=[AWL=0.213, 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 DZFmq7NChKsr for ; Wed, 18 Nov 2009 06:36:48 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 7F9C63A68D1 for ; Wed, 18 Nov 2009 06:36:48 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAIEajHI007928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 15:36:45 +0100 (MET) From: Martin Rex Message-Id: <200911181436.nAIEagLv024549@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 18 Nov 2009 15:36:42 +0100 (MET) In-Reply-To: <4B038974.9080001@pobox.com> from "Michael D'Errico" at Nov 17, 9 09:43:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:36:49 -0000 Michael D'Errico wrote: > > You forgot to mention: > > 4.3. SSLv3 > > SSLv3 does not support extensions and thus it is not possible to > securely renegotiate with SSLv3. Deployments wishing to renegotiate > securely will need to upgrade to at least TLS 1.0. > > Is there some secret agenda to kill off SSLv3? What is the point > of that? SSLv3 accounts for more than one-in-five connections as > reported to this list. There is an alternate proposal that does not > have this limitation, and is better in many other respects. Why do > you keep pushing this one? This statement about SSLv3 actually reverts history. The fact is, that SSLv3 has THE EXACT SAME provisions for TLS extensions as TLSv1.0. But TLS extensions seems to exclude _itself_ from being used with SSLv3 -- which looks like a pretty bad idea, given that the extensibility of TLSv1.0 and SSLv3 is verbatim the same. -Martin From simon@josefsson.org Wed Nov 18 06:41:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD713A67A6 for ; Wed, 18 Nov 2009 06:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 Cc2x62t-Nrhu for ; Wed, 18 Nov 2009 06:41:37 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 5D1F93A693C for ; Wed, 18 Nov 2009 06:41:36 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAIEfVGF004973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Nov 2009 15:41:32 +0100 From: Simon Josefsson To: References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022EBB.5030108@pobox.com> <808FD6E27AD4884E94820BC333B2DB774F30FE106F@NOK-EUMSG-01.mgdnok.nokia.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091118:pasi.eronen@nokia.com::Gezh34nyFOFJDx1e:YZC X-Hashcash: 1:22:091118:mike-list@pobox.com::rYznZAQA+TdMHgdK:57XW X-Hashcash: 1:22:091118:tls@ietf.org::QXpvr0vxHxIPOA/K:Y2fr Date: Wed, 18 Nov 2009 15:41:31 +0100 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE106F@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Wed, 18 Nov 2009 14:40:14 +0100") Message-ID: <87skcbyjxg.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:41:38 -0000 writes: > It seems many of the drawbacks of tls-renegotiation-00 you mention > are in fact addressed (to some degree) in version -01? (mainly > by including the "magic cipher suite") Compared to -01, what do > you think the main differences are? As far as I can tell, -01 does not fix (*) the problem for clients/servers that uses a) a SSLv3 implementation, or b) a original TLSv1 implementation (e.g., RFC 2246), or c) a TLSv1.1 implementation without support for extensions. Providing a solution only for the latest version of TLS is akin to ask people to upgrade to the latest release of a particular software rather than provide a simple fix to the existing deployed software. I'm hoping Martin will submit a draft on his ideas soon so we can compare the two. (*) Where "fix" means that TLS renegotiation works and is secure. /Simon > Best regards, > Pasi > (not wearing any hats) > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> ext Michael D'Errico >> Sent: 17 November, 2009 07:04 >> To: tls@ietf.org >> Subject: Re: [TLS] simplistic renego protection >> >> > If you want your alternative proposal to be considered, submit an >> > Internet draft and get some running code and feedback from >> > implementations showing your proposal would deploy protection to more >> > users than draft-rescorla-tls-renegotiation-00. Then you may sway >> > people to your viewpoint. >> >> Here is how draft-rescorla-tls-renegotiation-00 fails to protect the >> most people: >> >> - there are so many interoperability problems with TLS extensions >> that even the author of the draft suggests that a "lenient"[*] >> client not send the extension on its initial connection >> >> - there will be a transition period where some servers absolutely >> need to continue allowing unpatched clients to perform the current >> vulnerable renegotiation. >> >> - a lenient client's handshake without the RI extension looks just >> like an unpatched client that these unfortunate servers need to >> continue supporting >> >> - a man-in-the-middle can take advantage of these three points to >> victimize a patched client talking to a patched server! >> >> Just today many of us have converged on an alternate solution that does >> not have this serious problem. Instead of using extensions with all >> the myriad problems, the only bits-on-the-wire change is to include a >> single special cipher suite that signals to the server that the client >> wishes to use a new calculation of the Finished messages that includes >> the verify_data from the previous handshake. I suggested that an alert >> message could be used for the server to acknowledge back to the client. >> >> This uses only features that are present in SSLv3, so it is much more >> likely to be implemented quickly and correctly, and it does not require >> implementations to add any code for extension processing if they don't >> already support extensions. It also protects the lenient client and >> unfortunate servers above since there is no reason not to include the >> magic cipher suite in ALL handshakes. >> >> Here is a pointer to a summary of the proposal: >> >> http://www.ietf.org/mail-archive/web/tls/current/msg04393.html >> >> I am not a spec. writer, so someone else should write it up. If it is >> adopted I will implement it in my test server in short order for anyone >> to test against. >> >> Mike >> >> >> [*] a lenient client is one that would connect to any server regardless >> of whether it is patched or not. Since there is a not-insignificant >> chance that a server will barf on the use of extensions, and the >> lenient >> client wouldn't abort the handshake even if the extension is not >> returned by the server, it is less painful to just do what's always >> been done. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From Pasi.Eronen@nokia.com Wed Nov 18 06:57:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F673A6AB8 for ; Wed, 18 Nov 2009 06:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 EY4gW5BJJhSd for ; Wed, 18 Nov 2009 06:57:31 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DCFD83A6AA2 for ; Wed, 18 Nov 2009 06:57:30 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAIEv90K008880; Wed, 18 Nov 2009 16:57:26 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 16:57:13 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 16:57:08 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 18 Nov 2009 15:57:07 +0100 From: To: Date: Wed, 18 Nov 2009 15:57:06 +0100 Thread-Topic: [TLS] TLS Protocol Version Thread-Index: AcpoWyWS86ex0tpdSlypcKaU8/hnawAAPJpw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> References: <4B038434.6000005@pobox.com> from "Michael D'Errico" at Nov 17, 9 09:20:52 pm <200911181423.nAIENne8023747@fs4113.wdf.sap.corp> In-Reply-To: <200911181423.nAIENne8023747@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2009 14:57:08.0406 (UTC) FILETIME=[667BED60:01CA685F] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 14:57:32 -0000 Hmm... not all clients today support renegotiation, and IMHO the fix should be especially simple to deploy for those clients. Those clients could just include a magic cipher suite number in all client hellos, meaning "this is not a renegotiation". This would be extremely simple to implement, unlikely to break anything (old servers will ignore it), and could be shipped as soon as we pick the cipher suite number. Obviously, when the client does want to do secure renegotiation, we probably need two-way signalling, and we need to include the verify_data (or both) from the previous handshake somewhere (not necessarily on-the-wire) when doing renegotiation. Would it make sense to agree on the behavior for clients that never do renegotiation (1st paragraph above) before we know all the details for doing secure renegotiation (2nd paragraph above)? Best regards, Pasi (not wearing any hats) > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Martin Rex > Sent: 18 November, 2009 16:24 > To: Michael D'Errico > Cc: tls@ietf.org > Subject: Re: [TLS] TLS Protocol Version >=20 > If you are referring to the SSLv2 backwards-compatibility option, > that seems to be actually still used in Firefox 3.5 in the automatic > reconnect fallback should the server choke on TLS extensions. >=20 > And yes, *I* think it is a feature to even support this case, > because we're suggesting to quickly fix an urgent security problem > and _NOW_ is not the time to unnecessarily killing existing usage > scenarios, no matter how outdated they might look. >=20 > Requiring them to change that before shipping the patch would > be an unecessary burden, unnecessary risk and it could delay the > shipment of the patch. >=20 >=20 > If we want vendors and suppliers to ship this fix fast, then > we ought to try hard to _not_ break things, in particular, > not break things unnecessarily. >=20 >=20 > If, on the other hand, the TLS WG prefers the attitude: >=20 > "we know that using TLS extensions for the fix will break a number > of existing usage scenarios, but we think these usage scenarios > ought to be abandoned anyway, so we simply don't care." >=20 > then this will significantly slow down the deployment of patches, > since everyone will want to carefully test the existing usage > scenarios before risking to deploy the patch. >=20 >=20 > Improving interoperability with and tolerance for TLS extensions > could have been a working group item three years ago, when > the issue was brought to the attention of the TLS WG here > http://tools.ietf.org/html/draft-pettersen-tls-interop-experience-00 >=20 > when there was no time constraint on making TLS extensions usable > on he Internet. >=20 >=20 > -Martin >=20 >=20 > Michael D'Errico wrote: > > > > There is a misunderstanding. A client would offer exactly the same > version > > numbers it does today. Where the version number would differ is in > the > > ServerHello.version returned to the client ONLY IF the client sent > the > > "magic" cipher suite indicating it is expecting it. > > > > A single bit would be set to indicate that the server is also > patched. > > Martin wants to use the upper bit of the major version number, but I > think > > using the upper bit of the minor version number might be better. > Using the > > minor version would contain this to the 0x03 number space, so the > next TLS > > version can be 4.0 (0x0400), which will be larger than any of these > pseudo > > versions. > > > > Further, the version used in the record layer would not change > either. > > > > This combination of a magic cipher suite and a bit flip in the server > version > > is extremely compatible with all protocol versions including SSLv3, > whereas > > adding extensions to SSLv3 to do RI (even if only that one) could be > a > > hardship for many codebases. In fact this is even compatible with > the > > SSLv2 client hello! (Though I'm sure many of you would consider that > a > > flaw....) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Wed Nov 18 07:39:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE083A6972 for ; Wed, 18 Nov 2009 07:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_TOOL=2.3] 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 d44jHLKroD5Q for ; Wed, 18 Nov 2009 07:39:17 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id A72EE3A6A26 for ; Wed, 18 Nov 2009 07:39:16 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 90A3128C676 for ; Wed, 18 Nov 2009 16:39:18 +0100 (CET) Received: (qmail 47491 invoked from network); 18 Nov 2009 15:39:12 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Nov 2009 15:39:12 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 18 Nov 2009 16:39:11 +0100 From: Stefan Santesson To: Simon Josefsson , Message-ID: Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpoZUYRiOqLd7wZ10aqzM5mNveNFQ== In-Reply-To: <87skcbyjxg.fsf@mocca.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:39:18 -0000 I started off thinking that the simplistic approach is too much of a quick and dirty fix to be considered seriously, but I'm slowly beginning to like it more and more. I see some compelling arguments. 1) Is what has been stated before about the problems with extensions. If there are a considerable amount of implementations where adding extension support introduce significant problems, an extension less approach has merit. 2) Is that we seem to agree that TLS 1.3 will have an updated finished calculation anyway, not requiring the use of extensions. If we define that "future" finished calculation now and use it in the simplistic approach, then that would actually be closer to future versions of TLS, compared with an extension approach. If we consider the magic cipher suite signaling anyway in the extension approach. In that case, what is the added value of using extensions over just invoking the "future" and fixed finished calculation? Is it necessary for the server to signal to the client that is supports the upgraded finished calculation? It seems to me that an upgraded client could calculate it both ways and detect the server's capability based on which finished message the server sends. It may not be not optimal, but seems feasible. /Stefan On 09-11-18 3:41 PM, "Simon Josefsson" wrote: > writes: > >> It seems many of the drawbacks of tls-renegotiation-00 you mention >> are in fact addressed (to some degree) in version -01? (mainly >> by including the "magic cipher suite") Compared to -01, what do >> you think the main differences are? > > As far as I can tell, -01 does not fix (*) the problem for > clients/servers that uses > > a) a SSLv3 implementation, or > b) a original TLSv1 implementation (e.g., RFC 2246), or > c) a TLSv1.1 implementation without support for extensions. > > Providing a solution only for the latest version of TLS is akin to ask > people to upgrade to the latest release of a particular software rather > than provide a simple fix to the existing deployed software. > > I'm hoping Martin will submit a draft on his ideas soon so we can > compare the two. > > (*) Where "fix" means that TLS renegotiation works and is secure. > > /Simon > >> Best regards, >> Pasi >> (not wearing any hats) >> >>> -----Original Message----- >>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >>> ext Michael D'Errico >>> Sent: 17 November, 2009 07:04 >>> To: tls@ietf.org >>> Subject: Re: [TLS] simplistic renego protection >>> >>>> If you want your alternative proposal to be considered, submit an >>>> Internet draft and get some running code and feedback from >>>> implementations showing your proposal would deploy protection to more >>>> users than draft-rescorla-tls-renegotiation-00. Then you may sway >>>> people to your viewpoint. >>> >>> Here is how draft-rescorla-tls-renegotiation-00 fails to protect the >>> most people: >>> >>> - there are so many interoperability problems with TLS extensions >>> that even the author of the draft suggests that a "lenient"[*] >>> client not send the extension on its initial connection >>> >>> - there will be a transition period where some servers absolutely >>> need to continue allowing unpatched clients to perform the current >>> vulnerable renegotiation. >>> >>> - a lenient client's handshake without the RI extension looks just >>> like an unpatched client that these unfortunate servers need to >>> continue supporting >>> >>> - a man-in-the-middle can take advantage of these three points to >>> victimize a patched client talking to a patched server! >>> >>> Just today many of us have converged on an alternate solution that does >>> not have this serious problem. Instead of using extensions with all >>> the myriad problems, the only bits-on-the-wire change is to include a >>> single special cipher suite that signals to the server that the client >>> wishes to use a new calculation of the Finished messages that includes >>> the verify_data from the previous handshake. I suggested that an alert >>> message could be used for the server to acknowledge back to the client. >>> >>> This uses only features that are present in SSLv3, so it is much more >>> likely to be implemented quickly and correctly, and it does not require >>> implementations to add any code for extension processing if they don't >>> already support extensions. It also protects the lenient client and >>> unfortunate servers above since there is no reason not to include the >>> magic cipher suite in ALL handshakes. >>> >>> Here is a pointer to a summary of the proposal: >>> >>> http://www.ietf.org/mail-archive/web/tls/current/msg04393.html >>> >>> I am not a spec. writer, so someone else should write it up. If it is >>> adopted I will implement it in my test server in short order for anyone >>> to test against. >>> >>> Mike >>> >>> >>> [*] a lenient client is one that would connect to any server regardless >>> of whether it is patched or not. Since there is a not-insignificant >>> chance that a server will barf on the use of extensions, and the >>> lenient >>> client wouldn't abort the handshake even if the extension is not >>> returned by the server, it is less painful to just do what's always >>> been done. >>> _______________________________________________ >>> 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 stefan@aaa-sec.com Wed Nov 18 07:44:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A3C3A6885 for ; Wed, 18 Nov 2009 07:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_05=-1.11, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAE2jvl6xaAk for ; Wed, 18 Nov 2009 07:44:58 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id A58D33A6818 for ; Wed, 18 Nov 2009 07:44:58 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E320C28A4E8 for ; Wed, 18 Nov 2009 16:45:01 +0100 (CET) Received: (qmail 37460 invoked from network); 18 Nov 2009 15:44:55 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Nov 2009 15:44:55 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 18 Nov 2009 16:44:54 +0100 From: Stefan Santesson To: Stefan Santesson , Simon Josefsson , Message-ID: Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpoZUYRiOqLd7wZ10aqzM5mNveNFQAAMxyu In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:44:59 -0000 Disregard this question. It was a false thought. On 09-11-18 4:39 PM, "Stefan Santesson" wrote: > Is it necessary for the server to signal to the client that is supports the > upgraded finished calculation? It seems to me that an upgraded client could > calculate it both ways and detect the server's capability based on which > finished message the server sends. It may not be not optimal, but seems > feasible. From ekr@networkresonance.com Wed Nov 18 07:50:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44F33A6972 for ; Wed, 18 Nov 2009 07:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9NxePzdxVDL for ; Wed, 18 Nov 2009 07:50:07 -0800 (PST) Received: from kilo.networkresonance.com (cpc2-oxfd20-2-0-cust889.4-3.cable.virginmedia.com [86.26.27.122]) by core3.amsl.com (Postfix) with ESMTP id D78D03A6976 for ; Wed, 18 Nov 2009 07:50:06 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 210E869FE1E; Wed, 18 Nov 2009 15:41:38 +0000 (GMT) Date: Wed, 18 Nov 2009 15:41:37 +0000 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911181436.nAIEagLv024549@fs4113.wdf.sap.corp> References: <4B038974.9080001@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091118154138.210E869FE1E@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:50:08 -0000 At Wed, 18 Nov 2009 15:36:42 +0100 (MET), Martin Rex wrote: > > Michael D'Errico wrote: > > > > You forgot to mention: > > > > 4.3. SSLv3 > > > > SSLv3 does not support extensions and thus it is not possible to > > securely renegotiate with SSLv3. Deployments wishing to renegotiate > > securely will need to upgrade to at least TLS 1.0. > > > > Is there some secret agenda to kill off SSLv3? What is the point > > of that? SSLv3 accounts for more than one-in-five connections as > > reported to this list. There is an alternate proposal that does not > > have this limitation, and is better in many other respects. Why do > > you keep pushing this one? > > > This statement about SSLv3 actually reverts history. > > The fact is, that SSLv3 has THE EXACT SAME provisions for > TLS extensions as TLSv1.0. > > But TLS extensions seems to exclude _itself_ from being used with SSLv3 > -- which looks like a pretty bad idea, given that the extensibility > of TLSv1.0 and SSLv3 is verbatim the same. Well, I'm not taking any responsibility for that. I didn't write the original TLS extensions doc. That said, I suspect the feeling was that the IETF didn't have any control of SSLv3, and so couldn't mandate anything about it. -Ekr From ekr@networkresonance.com Wed Nov 18 08:00:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C5428C0EF for ; Wed, 18 Nov 2009 08:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MANGLED_TOOL=2.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ny6LSfEsl+M for ; Wed, 18 Nov 2009 08:00:07 -0800 (PST) Received: from kilo.networkresonance.com (cpc2-oxfd20-2-0-cust889.4-3.cable.virginmedia.com [86.26.27.122]) by core3.amsl.com (Postfix) with ESMTP id 94DF028C112 for ; Wed, 18 Nov 2009 08:00:06 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E8B5C69FE20; Wed, 18 Nov 2009 15:43:53 +0000 (GMT) Date: Wed, 18 Nov 2009 15:43:53 +0000 From: Eric Rescorla To: Simon Josefsson In-Reply-To: <87skcbyjxg.fsf@mocca.josefsson.org> References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022EBB.5030108@pobox.com> <808FD6E27AD4884E94820BC333B2DB774F30FE106F@NOK-EUMSG-01.mgdnok.nokia.com> <87skcbyjxg.fsf@mocca.josefsson.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091118154353.E8B5C69FE20@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:00:08 -0000 At Wed, 18 Nov 2009 15:41:31 +0100, Simon Josefsson wrote: > > writes: > > > It seems many of the drawbacks of tls-renegotiation-00 you mention > > are in fact addressed (to some degree) in version -01? (mainly > > by including the "magic cipher suite") Compared to -01, what do > > you think the main differences are? > > As far as I can tell, -01 does not fix (*) the problem for > clients/servers that uses > > a) a SSLv3 implementation, or > b) a original TLSv1 implementation (e.g., RFC 2246), or > c) a TLSv1.1 implementation without support for extensions. > > Providing a solution only for the latest version of TLS is akin to ask > people to upgrade to the latest release of a particular software rather > than provide a simple fix to the existing deployed software. I really don't understand this argument. Extensions are completely compatible with TLS 1.0, 1.1, and as has been observed by Martin, compatible in principle with SSLv3. Any fix will require some changes to people's software. I don't see how that consists at all of providing a solution only for the latest version of TLS. -Ekr From mike-list@pobox.com Wed Nov 18 08:04:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB8828C103 for ; Wed, 18 Nov 2009 08:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 bVAIpEumFKf9 for ; Wed, 18 Nov 2009 08:04:40 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id C0B7128C0DF for ; Wed, 18 Nov 2009 08:04:40 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id BF87C9F342 for ; Wed, 18 Nov 2009 11:04:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=2HIiPZK4PIA1 3Xt/Nm8FFBJAeJ8=; b=DNPkaw09uI9iUyuiOFp0/7PQqL7H6gcIOSLqT3sL/xc0 FYOC3mo93k6MYzT7RyL83CiJ/gBEXPynqU/zkn0I1F7a7Tj+aDBJvUImNnh7l8gs jWBYINcnv2rk1MqGihWBJGScGYalWu3YUTYRknr3qCuzQkbgtaE6usvyBbWV87Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=FONYfu TH9T7novCPmf0PPBXi3KVzUfIUYPL1NXxDw3HGw213QfbJzmD1U+v02Ul8ootJDf wFzX5nOV4XdtOhjyGmfVBAFdj8bbZwQqOP5GQmlVvaa2xzR71iE0DfapHRf+kdEj t8RV7tpyc+v6BAqCrcQIwD+9FbtCd5YQeqDoE= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B295C9F341 for ; Wed, 18 Nov 2009 11:04:38 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 305A39F340 for ; Wed, 18 Nov 2009 11:04:37 -0500 (EST) Message-ID: <4B041B5F.9070607@pobox.com> Date: Wed, 18 Nov 2009 08:05:51 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <20091117175000.653E669FBC6@kilo.networkresonance.com> <4B038974.9080001@pobox.com> <20091118080333.9D4FB69FC85@kilo.networkresonance.com> In-Reply-To: <20091118080333.9D4FB69FC85@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 12E65BE0-D45C-11DE-9901-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:04:41 -0000 Eric Rescorla wrote: > At Tue, 17 Nov 2009 21:43:16 -0800, > Michael D'Errico wrote: >> >> Is there some secret agenda to kill off SSLv3? What is the point >> of that? > > Well, I don't think it's a secret that many feel that it would > be good for people to upgrade from SSLv3 to TLS. TLS includes > a number of useful security fixes and extended functionality. > So, it's not clear it's great to go out of our way to preserve > its use indefinitely. The alternate method that does not use extensions is fairly complete. People seem to have a problem with putting the server bit in the version. I can understand that, and am open to other ideas. I've suggested using a checksum within the server random for this, but nobody has commented on it. Thus you can not say we need to "go out of our way", the work is already done, just needs some polish. >> SSLv3 accounts for more than one-in-five connections as >> reported to this list. > > Well, I've seen this claimed, but I haven't seen a citation for where > the data comes from. I'd be interested in seeing such a cite. The data > I've seen (and posted) suggests that servers support TLS very widely, > and certainly every piece of SSL/TLS-based software built on any even > remotely modern stack includes support for TLS, whatever it chooses to > negotiate. Does it really matter what the exact numbers are for SSL vs. TLS? If there are two proposals, one that supports both SSL and TLS, and another that only supports TLS, why would you want to choose the latter? >> There is an alternate proposal that does not >> have this limitation, and is better in many other respects. Why do >> you keep pushing this one? > > Because I feel that those other proposals are inferior in many > other respects? I'm not sure why this is so hard for you to > understand. You never give concrete reasons for your dislike of alternate ideas, just that you don't like them. That is your opinion and you are entitled to it, but since you don't give constructive suggestions for improvement, it is unhelpful. If you gave suggestions they would be considered and incorporated into an updated proposal. Personally I like extensions. A lot. But they are not needed for this, and because they are not widely implemented, forcing them on the population is ill-considered. Mike From mike-list@pobox.com Wed Nov 18 08:11:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E873A6976 for ; Wed, 18 Nov 2009 08:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 Ce7GbOiBEr9O for ; Wed, 18 Nov 2009 08:11:29 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id BFA0D3A6857 for ; Wed, 18 Nov 2009 08:11:29 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 3323B9F41C for ; Wed, 18 Nov 2009 11:11:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=pcDJZNqxDhDq 5yaSanaRtaIPsSc=; b=OU3tuub0XGV0Y5Oxi4ChrGjPTeuybtZaiX2BN2Ot8vXI eDfpy+OlcqKcy7pY+uOW9dHot5YE2fq6by0kd/BqX9j5RfrySFeioQiDbnjMCd7x O60i1yNOI6+5Rzo2Jxqo0KSJu+BGk2atJkSwf5yGs/fir3E3N8RZXeW+5uwd1I0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=gI0cur bKXMvvyO1IzSH45cvRsNAgOv3N9cXIlUptOLWO3lHLyx0bgjgo1fRJjcNiXNiNeC HtdSwXw9olUmgVO2wZ4aDBz7PuhTruELQsFfJQNH4V6TiGX8w/yg/6n9KGN78yas FyNT2CUdLvVpID7UxW/4ep+AGKfO6xDMnxxaw= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 2F6C59F41A for ; Wed, 18 Nov 2009 11:11:28 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id CAECA9F419 for ; Wed, 18 Nov 2009 11:11:27 -0500 (EST) Message-ID: <4B041CF8.6020903@pobox.com> Date: Wed, 18 Nov 2009 08:12:40 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B032EFC.6050707@pobox.com> <7E1DF37F1F42AB4E877E492C308E6AC40251FFC6@XCH57YKF.rim.net> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC40251FFC6@XCH57YKF.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 06F5CA0E-D45D-11DE-8F2E-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Implementation Experience X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:11:31 -0000 Robert Dugal wrote: > Other implementors may not experience the same code size cost as your findings. > Our product already implements several TLS extensions and has all the framework in place to add more. > Adding the extension support itself is trivial. Tieing renegotiation to the extension is trivial too. > We also have a framework for testing extensions. > I suspect the most code I would have to write is test and sample code. My code already supports extensions, and even so, the RI proposal required a lot more code than the alternative presented. That is a solid finding. I did nothing different than I always do to implement both; I did not try to influence the lines-of-code to make the alternative look more attractive. You are fortunate to already have extension support, but we need to be considerate to those that don't. It probably took you a long time to put that framework in place, refine it, test it, etc. Did you do that work at your leisure? Or were you faced with a ticking time bomb of an actively-exploitable serious security problem you needed to patch? Mike From mike-list@pobox.com Wed Nov 18 08:19:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1643A6961 for ; Wed, 18 Nov 2009 08:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 F3uO47ejoDuh for ; Wed, 18 Nov 2009 08:19:30 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 185C63A692B for ; Wed, 18 Nov 2009 08:19:30 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5AE069F50A for ; Wed, 18 Nov 2009 11:19:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=ET0goXptrvrn cRzGCV5xfNmZ7I8=; b=oTaVn2pSh7M1NnhQIIv1uMLBmqnn2rJClh+2JuORFAhO pmoteMnvq93KhgjkUmI1qydIE9e+0ZE2dAw/8PBHLDb0A5PIpQr/SH1bm+tJAPVA Pd+OxbfWYzAlxh8VUjIe3N89bfUlC17n3ED/vyGbCHWD6cPHmLhVbC3q8n8Kyl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=A69gE4 T74n/pw9YiCEBP3J3NOtCVjLizoFifitwyWS2HvbscQ6zjp00pycfFqWF4LIdBE+ ibuc16h42xEy18vADu7YmfAO93OdTboPu3AV2BSrJsspyh4hV+nnRBsV1zjD1LT2 SXuZ51zzJ2yil9FGo+RSyJqtWKHk5SVrLYaZo= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5782D9F509 for ; Wed, 18 Nov 2009 11:19:28 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id DCA689F508 for ; Wed, 18 Nov 2009 11:19:27 -0500 (EST) Message-ID: <4B041ED9.7080401@pobox.com> Date: Wed, 18 Nov 2009 08:20:41 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022EBB.5030108@pobox.com> <808FD6E27AD4884E94820BC333B2DB774F30FE106F@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE106F@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2528DBC8-D45E-11DE-922E-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:19:31 -0000 Pasi.Eronen@nokia.com wrote: > It seems many of the drawbacks of tls-renegotiation-00 you mention > are in fact addressed (to some degree) in version -01? (mainly > by including the "magic cipher suite") Compared to -01, what do > you think the main differences are? If you include a magic cipher suite, then you don't need to send *anything* else from client to server. This is what the alternative does that I implemented yesterday. The contents of the extension do not need to be transmitted over the wire since both peers know what it should contain. As long as that information gets added to the Finished message calculation (true in both proposals), the security hole is patched. Plus I believe the magic cipher suite in RI-01 is only for fallback behavior. The very fact that fallback behavior needs to be even considered in RI is a showstopper in my opinion. The alternative does not require any of that. Mike > Best regards, > Pasi > (not wearing any hats) > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> ext Michael D'Errico >> Sent: 17 November, 2009 07:04 >> To: tls@ietf.org >> Subject: Re: [TLS] simplistic renego protection >> >>> If you want your alternative proposal to be considered, submit an >>> Internet draft and get some running code and feedback from >>> implementations showing your proposal would deploy protection to more >>> users than draft-rescorla-tls-renegotiation-00. Then you may sway >>> people to your viewpoint. >> Here is how draft-rescorla-tls-renegotiation-00 fails to protect the >> most people: >> >> - there are so many interoperability problems with TLS extensions >> that even the author of the draft suggests that a "lenient"[*] >> client not send the extension on its initial connection >> >> - there will be a transition period where some servers absolutely >> need to continue allowing unpatched clients to perform the current >> vulnerable renegotiation. >> >> - a lenient client's handshake without the RI extension looks just >> like an unpatched client that these unfortunate servers need to >> continue supporting >> >> - a man-in-the-middle can take advantage of these three points to >> victimize a patched client talking to a patched server! >> >> Just today many of us have converged on an alternate solution that does >> not have this serious problem. Instead of using extensions with all >> the myriad problems, the only bits-on-the-wire change is to include a >> single special cipher suite that signals to the server that the client >> wishes to use a new calculation of the Finished messages that includes >> the verify_data from the previous handshake. I suggested that an alert >> message could be used for the server to acknowledge back to the client. >> >> This uses only features that are present in SSLv3, so it is much more >> likely to be implemented quickly and correctly, and it does not require >> implementations to add any code for extension processing if they don't >> already support extensions. It also protects the lenient client and >> unfortunate servers above since there is no reason not to include the >> magic cipher suite in ALL handshakes. >> >> Here is a pointer to a summary of the proposal: >> >> http://www.ietf.org/mail-archive/web/tls/current/msg04393.html >> >> I am not a spec. writer, so someone else should write it up. If it is >> adopted I will implement it in my test server in short order for anyone >> to test against. >> >> Mike >> >> >> [*] a lenient client is one that would connect to any server regardless >> of whether it is patched or not. Since there is a not-insignificant >> chance that a server will barf on the use of extensions, and the >> lenient >> client wouldn't abort the handshake even if the extension is not >> returned by the server, it is less painful to just do what's always >> been done. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > From mike-list@pobox.com Wed Nov 18 08:23:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986383A690F for ; Wed, 18 Nov 2009 08:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 I8c8d44mtDmn for ; Wed, 18 Nov 2009 08:23:31 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 60BA128C0ED for ; Wed, 18 Nov 2009 08:23:31 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C60D29F55A for ; Wed, 18 Nov 2009 11:23:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=V+RKJu7FJjIN /wCA6fDUjzPSPok=; b=OhHkoACY0bk9ZOWqbVgsKFT3d2sFAGLwGa4dQmL+rWE+ +T/SLRB9BXNNJ+VS2woOTqdAWDJpZaKNDPgtYRUscwuc6/COnl8EKXjP7miJ9f86 Whyv6A4aB44AXGdGg3ci2NWLg66k/Wgv5Nusk2h2kXePx5eHl6mt5a2aZhzmuLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=k6EBQL ImXyKL9E8mN8A3XDagfYc1ZKufrBa9TZzdUf7certRdobUNmleqjFSZmGa20sgO+ flV4a7iKXTLN2O1219AI0/j+AN1mlc4DigKtpiR99zsHW+gZ9hc2wVOKMBY/xjvx QAEHyMar1eVIzbjaIhKZLxQ8CtMDyFTX5Ew2o= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C16839F559 for ; Wed, 18 Nov 2009 11:23:29 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 1EE2E9F558 for ; Wed, 18 Nov 2009 11:23:28 -0500 (EST) Message-ID: <4B041FCA.9050507@pobox.com> Date: Wed, 18 Nov 2009 08:24:42 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B038434.6000005@pobox.com> from "Michael D'Errico" at Nov 17, 9 09:20:52 pm <200911181423.nAIENne8023747@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: B5102A70-D45E-11DE-9898-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:23:32 -0000 I like this idea -- it would be very easy to incorporate. Mike Pasi.Eronen@nokia.com wrote: > Hmm... not all clients today support renegotiation, and IMHO the fix > should be especially simple to deploy for those clients. Those > clients could just include a magic cipher suite number in all client > hellos, meaning "this is not a renegotiation". This would be extremely > simple to implement, unlikely to break anything (old servers will > ignore it), and could be shipped as soon as we pick the cipher suite > number. > > Obviously, when the client does want to do secure renegotiation, we > probably need two-way signalling, and we need to include the > verify_data (or both) from the previous handshake somewhere (not > necessarily on-the-wire) when doing renegotiation. > > Would it make sense to agree on the behavior for clients that never do > renegotiation (1st paragraph above) before we know all the details for > doing secure renegotiation (2nd paragraph above)? > > Best regards, > Pasi > (not wearing any hats) > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> ext Martin Rex >> Sent: 18 November, 2009 16:24 >> To: Michael D'Errico >> Cc: tls@ietf.org >> Subject: Re: [TLS] TLS Protocol Version >> >> If you are referring to the SSLv2 backwards-compatibility option, >> that seems to be actually still used in Firefox 3.5 in the automatic >> reconnect fallback should the server choke on TLS extensions. >> >> And yes, *I* think it is a feature to even support this case, >> because we're suggesting to quickly fix an urgent security problem >> and _NOW_ is not the time to unnecessarily killing existing usage >> scenarios, no matter how outdated they might look. >> >> Requiring them to change that before shipping the patch would >> be an unecessary burden, unnecessary risk and it could delay the >> shipment of the patch. >> >> >> If we want vendors and suppliers to ship this fix fast, then >> we ought to try hard to _not_ break things, in particular, >> not break things unnecessarily. >> >> >> If, on the other hand, the TLS WG prefers the attitude: >> >> "we know that using TLS extensions for the fix will break a number >> of existing usage scenarios, but we think these usage scenarios >> ought to be abandoned anyway, so we simply don't care." >> >> then this will significantly slow down the deployment of patches, >> since everyone will want to carefully test the existing usage >> scenarios before risking to deploy the patch. >> >> >> Improving interoperability with and tolerance for TLS extensions >> could have been a working group item three years ago, when >> the issue was brought to the attention of the TLS WG here >> http://tools.ietf.org/html/draft-pettersen-tls-interop-experience-00 >> >> when there was no time constraint on making TLS extensions usable >> on he Internet. >> >> >> -Martin >> >> >> Michael D'Errico wrote: >>> There is a misunderstanding. A client would offer exactly the same >> version >>> numbers it does today. Where the version number would differ is in >> the >>> ServerHello.version returned to the client ONLY IF the client sent >> the >>> "magic" cipher suite indicating it is expecting it. >>> >>> A single bit would be set to indicate that the server is also >> patched. >>> Martin wants to use the upper bit of the major version number, but I >> think >>> using the upper bit of the minor version number might be better. >> Using the >>> minor version would contain this to the 0x03 number space, so the >> next TLS >>> version can be 4.0 (0x0400), which will be larger than any of these >> pseudo >>> versions. >>> >>> Further, the version used in the record layer would not change >> either. >>> This combination of a magic cipher suite and a bit flip in the server >> version >>> is extremely compatible with all protocol versions including SSLv3, >> whereas >>> adding extensions to SSLv3 to do RI (even if only that one) could be >> a >>> hardship for many codebases. In fact this is even compatible with >> the >>> SSLv2 client hello! (Though I'm sure many of you would consider that >> a >>> flaw....) >> _______________________________________________ >> 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 jsalowey@cisco.com Wed Nov 18 08:26:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88D828C106 for ; Wed, 18 Nov 2009 08:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ufibPJNTMn6k for ; Wed, 18 Nov 2009 08:26:23 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F187D28C105 for ; Wed, 18 Nov 2009 08:26:22 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOauA0urR7H+/2dsb2JhbAC+PpgahDsE X-IronPort-AV: E=Sophos;i="4.44,766,1249257600"; d="scan'208";a="106067037" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2009 16:26:22 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAIGQLJC000382 for ; Wed, 18 Nov 2009 16:26:21 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.3959); Wed, 18 Nov 2009 08:26:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Nov 2009 08:26:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Adding a working group item for renegotiation fix Thread-Index: Acpoa9wJ8cqZzxhkSvqZC2Wy0BOoMQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 18 Nov 2009 16:26:21.0293 (UTC) FILETIME=[DD0DA9D0:01CA686B] Subject: [TLS] Adding a working group item for renegotiation fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:26:23 -0000 Chris has made some good points on the list. We may not have consensus on all the details yet, but we need to start moving forward with a solution. The basic approach of some sort of signaling and binding the previous finished message into the handshake are something all proposals have in common. I consulted with Pasi and we arrived at the following: a new working group item will be created, Eric Rescorla will be the editor and draft-rescorla-tls-renegotiation-01 will be the -00 starting point. Although the -00 draft does not reflect working group consensus, it does serve as the starting point. The exact mechanisms used in draft-rescorla-tls-renegotiation-01 may be changed as part of the working group review. =20 From mike-list@pobox.com Wed Nov 18 08:32:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107E83A6981 for ; Wed, 18 Nov 2009 08:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 1h1vpH3jnRWq for ; Wed, 18 Nov 2009 08:32:10 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id B8D523A6953 for ; Wed, 18 Nov 2009 08:32:10 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E473F80F64 for ; Wed, 18 Nov 2009 11:32:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Nu0QrszBLEif MvHBM0hFBm8eFBg=; b=vM/RyVF/5QCA5qEd/JW5J5geLUsblRRByAaEZebZrMpz MB5JTQvPhDMi9oqV89reFNSQGXqFUq+8MvLTRtDT3MtyccSdi1pVQ/FtZ4kxt8NG 4LPmHLxELgqRKq+UvvLt6HEclVkZ3Up8NDiHTWfZhv/fFT/hLA81Hyuyjzuhjmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=IRMK8f Ti9cQp0JG+4sS8BuVoL+9Gtesdb3Hd4xv/vGqtrWSUktPZ4/1nYhXTD+dksumUep +kyIlfb6bop+UGeOZANX8JhVBT4bJdunsOhZddIQDehWumJdfDubMsvaZ3Gyd9bk H5ORE7tawGeCipr+BgVhtuVkQFOxUyM5i+mIY= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D3FF380F63 for ; Wed, 18 Nov 2009 11:32:07 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 323D280F62 for ; Wed, 18 Nov 2009 11:32:07 -0500 (EST) Message-ID: <4B0421D0.50509@pobox.com> Date: Wed, 18 Nov 2009 08:33:20 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E9DE81D8-D45F-11DE-812E-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:32:12 -0000 Stefan Santesson wrote: > I started off thinking that the simplistic approach is too much of a quick > and dirty fix to be considered seriously, but I'm slowly beginning to like > it more and more. > > I see some compelling arguments. > > 1) Is what has been stated before about the problems with extensions. If > there are a considerable amount of implementations where adding extension > support introduce significant problems, an extension less approach has > merit. Agreed. > 2) Is that we seem to agree that TLS 1.3 will have an updated finished > calculation anyway, not requiring the use of extensions. If we define that > "future" finished calculation now and use it in the simplistic approach, > then that would actually be closer to future versions of TLS, compared with > an extension approach. This is one of the reasons I so dislike RI. The alternative presented modifies the Finished calculation in a way that is forward-compatible; it can be the default for future TLS versions, and that is the way it is implemented in my code now. If people don't like adding the previous verify_data to the stream of handshake messages so it gets hashed along with the rest, then please suggest a better way. One note: at first I didn't like the idea of inserting the verify_data immediately after the ServerHello, but when I implemented it, that was actually the most natural place to put it. > If we consider the magic cipher suite signaling anyway in the extension > approach. In that case, what is the added value of using extensions over > just invoking the "future" and fixed finished calculation? None as far as I can tell. Mike > Is it necessary for the server to signal to the client that is supports the > upgraded finished calculation? It seems to me that an upgraded client could > calculate it both ways and detect the server's capability based on which > finished message the server sends. It may not be not optimal, but seems > feasible. > > > /Stefan > > > > On 09-11-18 3:41 PM, "Simon Josefsson" wrote: > >> writes: >> >>> It seems many of the drawbacks of tls-renegotiation-00 you mention >>> are in fact addressed (to some degree) in version -01? (mainly >>> by including the "magic cipher suite") Compared to -01, what do >>> you think the main differences are? >> As far as I can tell, -01 does not fix (*) the problem for >> clients/servers that uses >> >> a) a SSLv3 implementation, or >> b) a original TLSv1 implementation (e.g., RFC 2246), or >> c) a TLSv1.1 implementation without support for extensions. >> >> Providing a solution only for the latest version of TLS is akin to ask >> people to upgrade to the latest release of a particular software rather >> than provide a simple fix to the existing deployed software. >> >> I'm hoping Martin will submit a draft on his ideas soon so we can >> compare the two. >> >> (*) Where "fix" means that TLS renegotiation works and is secure. >> >> /Simon >> >>> Best regards, >>> Pasi >>> (not wearing any hats) >>> >>>> -----Original Message----- >>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >>>> ext Michael D'Errico >>>> Sent: 17 November, 2009 07:04 >>>> To: tls@ietf.org >>>> Subject: Re: [TLS] simplistic renego protection >>>> >>>>> If you want your alternative proposal to be considered, submit an >>>>> Internet draft and get some running code and feedback from >>>>> implementations showing your proposal would deploy protection to more >>>>> users than draft-rescorla-tls-renegotiation-00. Then you may sway >>>>> people to your viewpoint. >>>> Here is how draft-rescorla-tls-renegotiation-00 fails to protect the >>>> most people: >>>> >>>> - there are so many interoperability problems with TLS extensions >>>> that even the author of the draft suggests that a "lenient"[*] >>>> client not send the extension on its initial connection >>>> >>>> - there will be a transition period where some servers absolutely >>>> need to continue allowing unpatched clients to perform the current >>>> vulnerable renegotiation. >>>> >>>> - a lenient client's handshake without the RI extension looks just >>>> like an unpatched client that these unfortunate servers need to >>>> continue supporting >>>> >>>> - a man-in-the-middle can take advantage of these three points to >>>> victimize a patched client talking to a patched server! >>>> >>>> Just today many of us have converged on an alternate solution that does >>>> not have this serious problem. Instead of using extensions with all >>>> the myriad problems, the only bits-on-the-wire change is to include a >>>> single special cipher suite that signals to the server that the client >>>> wishes to use a new calculation of the Finished messages that includes >>>> the verify_data from the previous handshake. I suggested that an alert >>>> message could be used for the server to acknowledge back to the client. >>>> >>>> This uses only features that are present in SSLv3, so it is much more >>>> likely to be implemented quickly and correctly, and it does not require >>>> implementations to add any code for extension processing if they don't >>>> already support extensions. It also protects the lenient client and >>>> unfortunate servers above since there is no reason not to include the >>>> magic cipher suite in ALL handshakes. >>>> >>>> Here is a pointer to a summary of the proposal: >>>> >>>> http://www.ietf.org/mail-archive/web/tls/current/msg04393.html >>>> >>>> I am not a spec. writer, so someone else should write it up. If it is >>>> adopted I will implement it in my test server in short order for anyone >>>> to test against. >>>> >>>> Mike >>>> >>>> >>>> [*] a lenient client is one that would connect to any server regardless >>>> of whether it is patched or not. Since there is a not-insignificant >>>> chance that a server will barf on the use of extensions, and the >>>> lenient >>>> client wouldn't abort the handshake even if the extension is not >>>> returned by the server, it is less painful to just do what's always >>>> been done. >>>> _______________________________________________ >>>> 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 mrex@sap.com Wed Nov 18 08:48:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3A63A67AA for ; Wed, 18 Nov 2009 08:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.043 X-Spam-Level: X-Spam-Status: No, score=-6.043 tagged_above=-999 required=5 tests=[AWL=0.206, 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 F1fEUKLf5t1e for ; Wed, 18 Nov 2009 08:48:00 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id F236F3A6767 for ; Wed, 18 Nov 2009 08:47:59 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAIGluea019702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 17:47:57 +0100 (MET) From: Martin Rex Message-Id: <200911181647.nAIGlueK002433@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Wed, 18 Nov 2009 17:47:56 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 18, 9 03:57:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:48:01 -0000 Pasi.Eronen@nokia.com wrote: > > Hmm... not all clients today support renegotiation, and IMHO the fix > should be especially simple to deploy for those clients. Those > clients could just include a magic cipher suite number in all client > hellos, meaning "this is not a renegotiation". This would be extremely > simple to implement, unlikely to break anything (old servers will > ignore it), and could be shipped as soon as we pick the cipher suite > number. > > Obviously, when the client does want to do secure renegotiation, we > probably need two-way signalling, and we need to include the > verify_data (or both) from the previous handshake somewhere (not > necessarily on-the-wire) when doing renegotiation. > > Would it make sense to agree on the behavior for clients that never do > renegotiation (1st paragraph above) before we know all the details for > doing secure renegotiation (2nd paragraph above)? Sounds fine to me. It doesn't interfere with the other work-in-progress in the TLS WG. There may be an interference with patch production for vendors/suppliers if they might need to ship two updates in a very short time instead of just one. I would prefer a positive description for that meaning, maybe "this is an initial handshake". There seems to be a ciphersuite range that only needs an Expert Review and no IANA action, so getting a number assigned there might be faster (require less formalities). We would later need an additional ciphersuite ID for signaling "I'm capable of secure TLS renegotiation", in case we can get consensus on signaling this through a ciphersuite ID as well. -Martin From mrex@sap.com Wed Nov 18 10:37:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B559C3A698D for ; Wed, 18 Nov 2009 10:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 wDrI-TYmamXa for ; Wed, 18 Nov 2009 10:37:38 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A5E333A6828 for ; Wed, 18 Nov 2009 10:37:36 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAIIbXBu028004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 19:37:33 +0100 (MET) From: Martin Rex Message-Id: <200911181837.nAIIbXJu009133@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 18 Nov 2009 19:37:33 +0100 (MET) In-Reply-To: <4B0421D0.50509@pobox.com> from "Michael D'Errico" at Nov 18, 9 08:33:20 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:37:38 -0000 Michael D'Errico wrote: > > > 2) Is that we seem to agree that TLS 1.3 will have an updated finished > > calculation anyway, not requiring the use of extensions. If we define that > > "future" finished calculation now and use it in the simplistic approach, > > then that would actually be closer to future versions of TLS, compared with > > an extension approach. > > This is one of the reasons I so dislike RI. The alternative presented > modifies the Finished calculation in a way that is forward-compatible; > it can be the default for future TLS versions, and that is the way it > is implemented in my code now. If people don't like adding the previous > verify_data to the stream of handshake messages so it gets hashed along > with the rest, then please suggest a better way. > > One note: at first I didn't like the idea of inserting the verify_data > immediately after the ServerHello, but when I implemented it, that was > actually the most natural place to put it. For the client, it is _the_ position where it reliably is in the posession of the Server.Finished from the previous TLS handshake. (Think of optimizing an renegotiation in order to protect the client identity, where one wants to piggy back the ClientHello of the immediate renegotiation onto the Client.Finished message. Does anyone remeber that the TLS WG gave the advice to people asking for identity protection to perform an initial client-anonymous TLS handshake directly followed by a renegotiation with client-cert authentication? (a related discussion what about gss-api authentication around 20-dec-2006, Subject: [TLS] Comments on TLS identity protection) -Martin From marsh@extendedsubset.com Wed Nov 18 10:51:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A6128C0ED for ; Wed, 18 Nov 2009 10:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 WjzlrwJLOXGJ for ; Wed, 18 Nov 2009 10:51:52 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id D85253A6834 for ; Wed, 18 Nov 2009 10:51:52 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NApd8-000J1b-Kg; Wed, 18 Nov 2009 18:51:50 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 89C4C667C; Wed, 18 Nov 2009 18:51:48 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/6Io7kJIzUA+wQM6/zKvJsidZzKv+fQpY= Message-ID: <4B044243.4070602@extendedsubset.com> Date: Wed, 18 Nov 2009 12:51:47 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022EBB.5030108@pobox.com> <808FD6E27AD4884E94820BC333B2DB774F30FE106F@NOK-EUMSG-01.mgdnok.nokia.com> <87skcbyjxg.fsf@mocca.josefsson.org> <20091118154353.E8B5C69FE20@kilo.networkresonance.com> In-Reply-To: <20091118154353.E8B5C69FE20@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:51:53 -0000 Eric Rescorla wrote: >> Providing a solution only for the latest version of TLS is akin to ask >> people to upgrade to the latest release of a particular software rather >> than provide a simple fix to the existing deployed software. > > I really don't understand this argument. Extensions are completely > compatible with TLS 1.0, 1.1, and as has been observed by > Martin, compatible in principle with SSLv3. Any fix will require > some changes to people's software. I don't see how that consists > at all of providing a solution only for the latest version of > TLS. It appears that many SSLv3 servers and some "TLS1.0" do not correctly ignore unrecognized extensions. Therefore, it represents a breaking protocol change for the owners of such systems. Most admins are responsible for a variety of systems and no tools seem readily available to even determine one's status. - Marsh From nelson@bolyard.me Wed Nov 18 11:01:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875113A67A3 for ; Wed, 18 Nov 2009 11:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 2mNDEJ7wQzZG for ; Wed, 18 Nov 2009 11:01:38 -0800 (PST) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id 1071D28C0FC for ; Wed, 18 Nov 2009 11:01:36 -0800 (PST) Received: (qmail 29857 invoked from network); 18 Nov 2009 19:01:35 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 18 Nov 2009 19:01:35 -0000 Message-ID: <4B044419.5040707@bolyard.me> Date: Wed, 18 Nov 2009 10:59:37 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <4B038434.6000005@pobox.com> from "Michael D'Errico" at Nov 17, 9 09:20:52 pm <200911181423.nAIENne8023747@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:01:42 -0000 On 2009-11-18 06:57 PST, Pasi.Eronen@nokia.com wrote: > Hmm... not all clients today support renegotiation, and IMHO the fix > should be especially simple to deploy for those clients. Those clients > could just include a magic cipher suite number in all client hellos, > meaning "this is not a renegotiation". As I read EKR's -01 draft, the magic cipher suite means "IS renegotiation". You're proposing that the magic cipher suite means "is NOT renegotiation". To avoid confusion, I suggest we start explicitly calling it the "IS renegotiation cipher suite" or the "is NOT renegotiation cipher suite". Otherwise, confusion may take hold. > This would be extremely simple to implement, This is going to be a LOT more code for me (for NSS) than RI was because it means this new magic number must be special cased EVERYWHERE that cipher suite numbers are handled. The code must ensure that the local application cannot enable it or disable it. The code must not report it as a supported cipher suite to the local application. The code that checks every cipher suite to see that the necessary crypto algorithms, certs and keys for it are locally present must not perform those checks for this cipher suite. The code must ensure at both ends that this suite number never gets negotiated. The work to do this is not particularly difficult or complex. It's just a lot of code strewn all over. > unlikely to break anything (old servers will ignore it), and could be > shipped as soon as we pick the cipher suite number. > Obviously, when the client does want to do secure renegotiation, we > probably need two-way signalling, Right. It's signalling the other way that is the potential show stopper for this proposal. RI has simple symmetry and doesn't complicate TLS's protocol versioning scheme at all. IMO, it is an absolute requirement of any proposed solution that it not complicate TLS versioning. > and we need to include the verify_data (or both) from the previous > handshake somewhere (not necessarily on-the-wire) when doing > renegotiation. > > Would it make sense to agree on the behavior for clients that never do > renegotiation (1st paragraph above) before we know all the details for > doing secure renegotiation (2nd paragraph above)? IMO, no. We must engineer a complete solution. From Pasi.Eronen@nokia.com Wed Nov 18 11:03:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FBFA3A6876 for ; Wed, 18 Nov 2009 11:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 8Hw9kAuTemU3 for ; Wed, 18 Nov 2009 11:03:04 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0302E3A67EE for ; Wed, 18 Nov 2009 11:03:03 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAIJ2s8u007995; Wed, 18 Nov 2009 13:03:01 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 21:02:59 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 21:02:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 21:02:50 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 18 Nov 2009 20:02:49 +0100 From: To: Date: Wed, 18 Nov 2009 20:02:47 +0100 Thread-Topic: [TLS] TLS Protocol Version Thread-Index: AcpobvVDToBEAatgRqifscrqD90IKAAEcQcg Message-ID: <808FD6E27AD4884E94820BC333B2DB774F30FE12B7@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 18, 9 03:57:06 pm <200911181647.nAIGlueK002433@fs4113.wdf.sap.corp> In-Reply-To: <200911181647.nAIGlueK002433@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2009 19:02:50.0367 (UTC) FILETIME=[B960A8F0:01CA6881] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:03:05 -0000 BTW, there's another common renegotiation case where a "low-hanging fruit" (trivial-to-implement solution known not to cause interop problems with broken servers) exists: changing from server-only authentication to mutual authentication (with certificate-based=20 cipher suites). In this case, the client could include a magic "This is a renegotiation, but with same server certificate" cipher suite in the renegotiation client hello, and verify that the server certs in the old and new sessions are identical (bitwise). This would be just a magic cipher suite number: no other on-the-wire changes, and no changes to Finished message calculations. But the server would know this renegotiation is secure, and could proceed even if it prohibited "old-style" insecure renegotiation. (In some sense, this is a bit like channel binding with=20 'tls-server-end-point' channel binding type.) This obviously doesn't work when non-certificate-based cipher suites (like DH_anon) are involved, or when the goal is to actually change the certificate (probably doesn't make sense in most apps, but could make for some). And like the (even simpler) "This is not a renegotiation" magic cipher=20 suite, it doesn't allow the client to implement a "strict" policy where=20 it refuses to talk (even in initial handshakes) to non-upgraded servers. But since many servers that don't support renegotiation (either never did, or have now disabled it), and thus are not vulnerable, will probably never implement the protocol changes, I'm not sure such a "strict" policy for clients would ever be usable (except perhaps in some small and tightly controlled deployments -- which could quite well implement the "fully featured" solution with TLS extensions). Best regards, Pasi (not wearing any hats) > -----Original Message----- > From: ext Martin Rex [mailto:mrex@sap.com] > Sent: 18 November, 2009 18:48 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: mrex@sap.com; tls@ietf.org > Subject: Re: [TLS] TLS Protocol Version >=20 > Pasi.Eronen@nokia.com wrote: > > > > Hmm... not all clients today support renegotiation, and IMHO the fix > > should be especially simple to deploy for those clients. Those > > clients could just include a magic cipher suite number in all client > > hellos, meaning "this is not a renegotiation". This would be > extremely > > simple to implement, unlikely to break anything (old servers will > > ignore it), and could be shipped as soon as we pick the cipher suite > > number. > > > > Obviously, when the client does want to do secure renegotiation, we > > probably need two-way signalling, and we need to include the > > verify_data (or both) from the previous handshake somewhere (not > > necessarily on-the-wire) when doing renegotiation. > > > > Would it make sense to agree on the behavior for clients that never > do > > renegotiation (1st paragraph above) before we know all the details > for > > doing secure renegotiation (2nd paragraph above)? >=20 > Sounds fine to me. >=20 > It doesn't interfere with the other work-in-progress in the TLS WG. > There may be an interference with patch production for > vendors/suppliers > if they might need to ship two updates in a very short time instead > of just one. >=20 >=20 > I would prefer a positive description for that meaning, > maybe "this is an initial handshake". >=20 >=20 > There seems to be a ciphersuite range that only needs an > Expert Review and no IANA action, so getting a number assigned > there might be faster (require less formalities). >=20 > We would later need an additional ciphersuite ID for signaling > "I'm capable of secure TLS renegotiation", in case we can get > consensus on signaling this through a ciphersuite ID as well. >=20 >=20 > -Martin From mrex@sap.com Wed Nov 18 11:10:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7973E3A688C for ; Wed, 18 Nov 2009 11:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.055 X-Spam-Level: X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=0.194, 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 rDBoDJBzasCW for ; Wed, 18 Nov 2009 11:10:49 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DCE003A6855 for ; Wed, 18 Nov 2009 11:10:48 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAIJAgka000611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 20:10:42 +0100 (MET) From: Martin Rex Message-Id: <200911181910.nAIJAe26011062@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Wed, 18 Nov 2009 20:10:40 +0100 (MET) In-Reply-To: <4B044419.5040707@bolyard.me> from "Nelson B Bolyard" at Nov 18, 9 10:59:37 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:10:50 -0000 Nelson B Bolyard wrote: > > On 2009-11-18 06:57 PST, Pasi.Eronen@nokia.com wrote: > > Hmm... not all clients today support renegotiation, and IMHO the fix > > should be especially simple to deploy for those clients. Those clients > > could just include a magic cipher suite number in all client hellos, > > meaning "this is not a renegotiation". > > As I read EKR's -01 draft, the magic cipher suite means "IS renegotiation". > You're proposing that the magic cipher suite means "is NOT renegotiation". > To avoid confusion, I suggest we start explicitly calling it the > "IS renegotiation cipher suite" or the "is NOT renegotiation cipher suite". > Otherwise, confusion may take hold. > > > This would be extremely simple to implement, > > This is going to be a LOT more code for me (for NSS) than RI was because > it means this new magic number must be special cased EVERYWHERE that cipher > suite numbers are handled. The code must ensure that the local application > cannot enable it or disable it. The code must not report it as a supported > cipher suite to the local application. The code that checks every cipher > suite to see that the necessary crypto algorithms, certs and keys for it > are locally present must not perform those checks for this cipher suite. > The code must ensure at both ends that this suite number never gets > negotiated. The work to do this is not particularly difficult or complex. > It's just a lot of code strewn all over. How about approaching this from a different angle. You seem to be several software layer above where this change should go. The TLS client should add that special ciphersuite ID when composing the ClientHello handshake message. This is _NOT_ intended to be something configurable to applications through regular ciphersuite selections. On the TLS server, the code that parses the ServerHello should recognize this special ciphersuite ID, convert it into a seperate state variable in the securityparameters of the connection state and _NOT_ pass it up to software layers above or even higher to applications between real ciphersuite IDs. What were doing here is some sort of "compression" on the handshake information in ClientHello and ServerHello. The compression code that generate the ClientHello adds the stuff, the decompression code that parses ServerHello removes the stuff. I don't mind when you make the information itself available to the application or configurable to the application, but _PLEASE_ do not make it through the standard ciphersuite configuration options, that we have re-purposed here to get our signaling over the network in existing PDUs. -Martin From mrex@sap.com Wed Nov 18 11:34:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B3D3A6891 for ; Wed, 18 Nov 2009 11:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.188, 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 doMiVGEUTgNs for ; Wed, 18 Nov 2009 11:34:05 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 6C2583A6851 for ; Wed, 18 Nov 2009 11:34:05 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAIJY2MB024659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 20:34:02 +0100 (MET) From: Martin Rex Message-Id: <200911181934.nAIJY1dW012252@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Wed, 18 Nov 2009 20:34:01 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE12B7@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 18, 9 08:02:47 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:34:06 -0000 Pasi.Eronen@nokia.com wrote: > > BTW, there's another common renegotiation case where a "low-hanging > fruit" (trivial-to-implement solution known not to cause interop > problems with broken servers) exists: changing from server-only > authentication to mutual authentication (with certificate-based > cipher suites). I'm sure there are plenty of nifty things we can add that don't need more than a single bit for signaling. I just wished the designers of TLSv1.0 had replaced the ClientHello extensibility that was present in SSLv3 already (at least in the spec that happened after the implementations) Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message must match the description of the message precisely. already in 1998 with a uint32 plus optional yet-to-be-defined data and added this to the ServerHello as well. Then there would be an easy-to-use bitfield from one could draw bit-flags -- and the extensions-intolerance would have been ironed out by know. The TLS extension mechanism is pretty heavyweight. I find it somewhat strange for the IETF to adopt a handshake protocol with pretty much no slack (TLSv1.0). (buzzwords like "side-channel" or "covert-channel" are a total non-issue here. Both ClientHello and ServerHello contain 60 octets of data (64 octets if you randomize gmt_unix_time) that is specified and allowed to look random, and a ciphersuite list where you can use perfectly valid (but frowned upon) integrity-only ciphersuites for signaling (you could also signal by the sequence of the ciphersuites...), and then client and server can use the space of the 60/64 random octets in ClientHello and ServerHello to exchange arbitrary data. And when they encrypt this data, it will even look less suspicious!) -Martin From mrex@sap.com Wed Nov 18 12:00:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8A028C10A for ; Wed, 18 Nov 2009 12:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_TOOL=2.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 TCakJEb5KnXS for ; Wed, 18 Nov 2009 12:00:48 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A979A3A68BC for ; Wed, 18 Nov 2009 12:00:31 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAIK0S6v019643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 21:00:28 +0100 (MET) From: Martin Rex Message-Id: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Wed, 18 Nov 2009 21:00:26 +0100 (MET) In-Reply-To: <20091118154353.E8B5C69FE20@kilo.networkresonance.com> from "Eric Rescorla" at Nov 18, 9 03:43:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 20:00:48 -0000 Eric Rescorla wrote: > > At Wed, 18 Nov 2009 15:41:31 +0100, > Simon Josefsson wrote: > > > > writes: > > > > > It seems many of the drawbacks of tls-renegotiation-00 you mention > > > are in fact addressed (to some degree) in version -01? (mainly > > > by including the "magic cipher suite") Compared to -01, what do > > > you think the main differences are? > > > > As far as I can tell, -01 does not fix (*) the problem for > > clients/servers that uses > > > > a) a SSLv3 implementation, or > > b) a original TLSv1 implementation (e.g., RFC 2246), or > > c) a TLSv1.1 implementation without support for extensions. > > > > Providing a solution only for the latest version of TLS is akin to ask > > people to upgrade to the latest release of a particular software rather > > than provide a simple fix to the existing deployed software. > > I really don't understand this argument. Extensions are completely > compatible with TLS 1.0, 1.1, and as has been observed by > Martin, compatible in principle with SSLv3. Any fix will require > some changes to people's software. I don't see how that consists > at all of providing a solution only for the latest version of TLS. We've been through this a few times. There are going to be components out there that will not get patched. They might not implement renegotiation (or have it disabled) and they're therefore not even vulnerable. But we can not simply brick them (deny to talk SSL to them in the future). So Browsers will likely have to continue to offer an fallback to extension-less ClientHello. As long as Browsers do that, we can not protect them from a downgrade attack -- unless we change the signaling for the protected renegotiation into something that is going to be interoperable with those old, unpatched and some even non-vulnerable servers that are going to be with us for quite a while. -Martin From marsh@extendedsubset.com Wed Nov 18 12:24:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B0F3A6984 for ; Wed, 18 Nov 2009 12:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.279, 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 9PlF7pcVl-6O for ; Wed, 18 Nov 2009 12:24:20 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 504373A68DA for ; Wed, 18 Nov 2009 12:24:20 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NAr4b-000Lvp-SK; Wed, 18 Nov 2009 20:24:18 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D5646667C; Wed, 18 Nov 2009 20:24:14 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+eshU4EXgN7JlFnUspRPWuZUm9Ma8EIK0= Message-ID: <4B0457ED.4070607@extendedsubset.com> Date: Wed, 18 Nov 2009 14:24:13 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <4B038434.6000005@pobox.com> from "Michael D'Errico" at Nov 17, 9 09:20:52 pm <200911181423.nAIENne8023747@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 20:24:21 -0000 Pasi.Eronen@nokia.com wrote: > Hmm... not all clients today support renegotiation, and IMHO the fix > should be especially simple to deploy for those clients. Those > clients could just include a magic cipher suite number in all client > hellos, meaning "this is not a renegotiation". This would be extremely > simple to implement, unlikely to break anything (old servers will > ignore it), and could be shipped as soon as we pick the cipher suite > number. Perhaps they could simply advertise support for the fix with no other implementation changes. If they really don't support renegotiation, then they'll never have to exchange data under whatever modified method is used to enforce the binding. - Marsh From mrex@sap.com Wed Nov 18 13:01:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839BE3A67FA for ; Wed, 18 Nov 2009 13:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.209, 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 F7OmNz-V2OXd for ; Wed, 18 Nov 2009 13:01:52 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 60A163A67F5 for ; Wed, 18 Nov 2009 13:01:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAIL1lHN018984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 22:01:47 +0100 (MET) From: Martin Rex Message-Id: <200911182101.nAIL1jjj017483@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Wed, 18 Nov 2009 22:01:45 +0100 (MET) In-Reply-To: from "Yoav Nir" at Nov 18, 9 10:00:52 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:01:53 -0000 Yoav Nir wrote: > > I'm very much against that. > > The protocol version is something everyone looks at: clients, servers > and middleboxes. > > OTOH the server_random field is treated as random. Yes, even the > timestamp part. > > I really believe that's the place for the server to signal. What we're trying to do is to compress more information into the original (SSLv3) ServerHello data structure than the original designer provided room for. What is an engineer going do when given the task to transport some information in a container that is shorter than the information? Compression comes to mind. Which parts of the ServerHello are compressible? ServerHello.server_version is a container of 16 bits, and all information it had to carry in its life so far is like 2.something bits. Since the value range of server_version is tightly controlled (by the maintainers of the specs), we're not going to run into accidental collisions. The problem with the randoms is, that they're not compressible. we can not prevent accidental collisions. In theory, the gmt_unix_time had been a good candidate with a predictable collision probability -- just that some implementors seem to have goofed this idea by randomizing the content. The correct approach to not leak your exact clock would have been to fuzz the seconds. E.g. use a random but fixed bias (the lowest 8-16 bits) and select a new random bias every couple of hours. This would have left the collision probability predictable in case someone needs to re-purpose that field in the handshake message. I would consider fuzzing the lower part of gmt_time_unix still within the spec (bending a little bit, but still in the spec). Replacing it with entirely random data is breaking the spec, and it is where most of the interop problems in our protocols come from. Bending a spec when you have a justification is OK, breaking the spec is not. > > As for the client signal, the fake ciphersuite is clean and > not-elegant-but-ok. However, for no reason other than aesthetics, the > client signal should be similar to that of the server. And I'd use two > magic values: > - SUPPORT - (client or server) will use new calculation of Finished > message > - SAFE - (server only) Renegotiation is disabled. This allows a quicker > fix. Not sure if this is really needed, though. > > Then you just add the old verify_data to the Finished message, and > there's no need for extensions. In theory the two values sound nice, In practice they do not necessarily make a difference. All of the handshake data is only protected by the finished messages, (plus the CertificateVerify when a client certificate is used). In principle, what were trying to "negotiate" is the information from the client "I don't like to get screwed with the old TLS renego" and the confirmation from the server "I'm not going to screw you with the old TLS renego" and the finished message verification will determine whether client and server actually sent what each other received (no attacker doctoring the messages). Before either communication peer has not verified the others finished messsage (CertificateVerify can also authenticate the initial part of the handshake, but be careful about premature conclusions!!), _no_ part of the TLS handshake should be considered authentic. You can detect some modifications earlier, but without finished message verification you not make any assumptions. -Martin From mrex@sap.com Wed Nov 18 13:22:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DC23A6846 for ; Wed, 18 Nov 2009 13:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.204, 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 oyGL79M7gzeZ for ; Wed, 18 Nov 2009 13:22:54 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 93FB83A67A1 for ; Wed, 18 Nov 2009 13:22:54 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAILMnOU003976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 22:22:49 +0100 (MET) From: Martin Rex Message-Id: <200911182122.nAILMm23018985@fs4113.wdf.sap.corp> To: rdugal@certicom.com (Robert Dugal) Date: Wed, 18 Nov 2009 22:22:48 +0100 (MET) In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC40251FFD4@XCH57YKF.rim.net> from "Robert Dugal" at Nov 18, 9 07:39:20 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:22:55 -0000 Robert Dugal wrote: > > I noticed you said this in the jabber log http://www.ietf.org/jabber/logs/tls/2009-11-12.txt > > [06:31:06] It occurred to me the other day that there is > a special case where hte server does not need to refuse renegotiation: > when the client has sent no data yet. > [06:31:20] This would allow step-up/SGC to continue to work > assuming we cared it) Define "client has sent no data yet" ? There is an implementors note in TLSv1.2, section about "Fragmentation" that is as old as SSLv3 which requires that application can be arbitrarily interleaved with a renegotiation handshake. So the MitM can inject the data before forwarding the ChangeCipherSpec message. So whenever you implement something for this special case, make sure that your TLS implementation checks "client has sent no data yet" concurrently with verifying the finished message (unless it fails reliably when receiving application data during the renegotiation handshake). > > Our products do support step-up/SGC and some customers may still be > using it, or at least have servers with SGC certificates. > Since there is no vulnerability is this special case, should > some note be added to the draft? You mean like enumerating conceivable usage scenarios that TLS extension RI is very likely to break? Maybe a spec where that section is very small or empty would be more appreciated by the community. -Martin From mrex@sap.com Wed Nov 18 13:42:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF9A3A69FD for ; Wed, 18 Nov 2009 13:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.198, 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 WFrQKjVjkgjE for ; Wed, 18 Nov 2009 13:42:48 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E0D843A6884 for ; Wed, 18 Nov 2009 13:42:47 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAILgi0L021678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 22:42:44 +0100 (MET) From: Martin Rex Message-Id: <200911182142.nAILghdY020026@fs4113.wdf.sap.corp> To: uri@ll.mit.edu (Blumenthal Uri - 0662 - MITLL) Date: Wed, 18 Nov 2009 22:42:43 +0100 (MET) In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3E3@LLE2K7-BE01.mitll.ad.local> from "Blumenthal, Uri - 0662 - MITLL" at Nov 18, 9 07:02:58 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:42:49 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > > After following this discussion for a while, I can say that I too > am against fooling around with protocol version number > (or with re-purposing an existing field). A clean extension-based > solution is what's needed. And if SSLv3 can't/won't support it - so be it. This is definitely not about fooling around. It is strictly about compressing the information in the ServerHello.server_version field while it travels the network in a fashion that the client will understand perfectly well. I expect that we will want to make the protected renegotiation part of the TLSv1.3 base spec, and will prohibit the use of the unprotected TLS renegotiation if the protocol version TLSv1.3 is negotiated. So it is actually the exact same position in the client code (parsing of ServerHello) that will decide when secure renegotiation is used there. if ( 0!=(ServerHello.server_version & PATCHED_RENEGO_FLAG) ) || (ServerHello.server_version & ~PATCHED_RENEGO_FLAG) >= TLSv13 ) { s->use_secure_renegotiation = TRUE; } So it is a very good and the most natural place. We are definitely changing an essential part of the protocol. But we are also changing it orthogonal to regular TLS-versioning, i.e. were _NOT_ creating TLSv1.3, but instead we are creating modified protocol versions of SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2 What exactly is you problem with sacrificing a bit of the server_version network encoding(!) in order to signal a protocol change that is orthogonal to TLS protocol versioning? -Martin From uri@ll.mit.edu Wed Nov 18 14:13:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB5A3A683D for ; Wed, 18 Nov 2009 14:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8IJfI8yVyzV for ; Wed, 18 Nov 2009 14:13:09 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id D59833A68E1 for ; Wed, 18 Nov 2009 14:13:08 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAIMD1fQ008754; Wed, 18 Nov 2009 17:13:01 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAZnayXN; Wed Nov 18 16:57:56 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Wed, 18 Nov 2009 16:57:56 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'mrex@sap.com'" Date: Wed, 18 Nov 2009 16:57:52 -0500 Thread-Topic: [TLS] TLS Protocol Version Thread-Index: AcpomBrTp7zIgsEhQSi9sR5RStvhkgAAhQB7 Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3E6@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 22:13:10 -0000 SSBhbSBjb25jZXJuZWQgb2YgIm92ZXJsb2FkaW5nIiBmaWVsZHMgYW5kIGFzc2lnbmluZyBhbiBh ZGRpdGlvbmFsIG1lYW5pbmcgdG8gdGhlbSB0aGF0IHRoZXkgZGlkIG5vdCBoYXZlLiBOb3QgYSBj bGVhbiBkZXNpZ24gb3IgcHJvZ3JhbW1pbmcgcHJhY3RpY2UsIGFuZCBwcm9uZSB0byBjYXVzaW5n IHBlb3BsZSBvciBjb2RlIHVzZWQgdG8gdGhlICJvbGQiIG1lYW5pbmcgdG8gc3R1bWJsZS4NCg0K SXMgaXQgdGhlIG9ubHkgdmlhYmxlIHNvbHV0aW9uPz8/DQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KRnJvbTogTWFydGluIFJleCA8bXJleEBzYXAuY29tPg0KVG86IEJsdW1lbnRo YWwsIFVyaSAtIDA2NjIgLSBNSVRMTA0KQ2M6IHRsc0BpZXRmLm9yZyA8dGxzQGlldGYub3JnPg0K U2VudDogV2VkIE5vdiAxOCAxNjo0Mjo0MyAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBUTFMgUHJv dG9jb2wgVmVyc2lvbg0KDQpCbHVtZW50aGFsLCBVcmkgLSAwNjYyIC0gTUlUTEwgd3JvdGU6DQo+ IA0KPiBBZnRlciBmb2xsb3dpbmcgdGhpcyBkaXNjdXNzaW9uIGZvciBhIHdoaWxlLCBJIGNhbiBz YXkgdGhhdCBJIHRvbw0KPiBhbSBhZ2FpbnN0IGZvb2xpbmcgYXJvdW5kIHdpdGggcHJvdG9jb2wg dmVyc2lvbiBudW1iZXINCj4gKG9yIHdpdGggcmUtcHVycG9zaW5nIGFuIGV4aXN0aW5nIGZpZWxk KS4gQSBjbGVhbiBleHRlbnNpb24tYmFzZWQNCj4gc29sdXRpb24gaXMgd2hhdCdzIG5lZWRlZC4g QW5kIGlmIFNTTHYzIGNhbid0L3dvbid0IHN1cHBvcnQgaXQgLSBzbyBiZSBpdC4NCg0KVGhpcyBp cyBkZWZpbml0ZWx5IG5vdCBhYm91dCBmb29saW5nIGFyb3VuZC4NCkl0IGlzIHN0cmljdGx5IGFi b3V0IGNvbXByZXNzaW5nIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUNClNlcnZlckhlbGxvLnNlcnZl cl92ZXJzaW9uIGZpZWxkIHdoaWxlIGl0IHRyYXZlbHMgdGhlIG5ldHdvcmsNCmluIGEgZmFzaGlv biB0aGF0IHRoZSBjbGllbnQgd2lsbCB1bmRlcnN0YW5kIHBlcmZlY3RseSB3ZWxsLg0KDQpJIGV4 cGVjdCB0aGF0IHdlIHdpbGwgd2FudCB0byBtYWtlIHRoZSBwcm90ZWN0ZWQgcmVuZWdvdGlhdGlv bg0KcGFydCBvZiB0aGUgVExTdjEuMyBiYXNlIHNwZWMsIGFuZCB3aWxsIHByb2hpYml0IHRoZSB1 c2Ugb2YgdGhlDQp1bnByb3RlY3RlZCBUTFMgcmVuZWdvdGlhdGlvbiBpZiB0aGUgcHJvdG9jb2wg dmVyc2lvbiBUTFN2MS4zDQppcyBuZWdvdGlhdGVkLg0KDQpTbyBpdCBpcyBhY3R1YWxseSB0aGUg ZXhhY3Qgc2FtZSBwb3NpdGlvbiBpbiB0aGUgY2xpZW50IGNvZGUNCihwYXJzaW5nIG9mIFNlcnZl ckhlbGxvKSB0aGF0IHdpbGwgZGVjaWRlIHdoZW4gc2VjdXJlIHJlbmVnb3RpYXRpb24NCmlzIHVz ZWQgdGhlcmUuDQoNCiAgIGlmICggMCE9KFNlcnZlckhlbGxvLnNlcnZlcl92ZXJzaW9uICYgUEFU Q0hFRF9SRU5FR09fRkxBRykgKQ0KICAgICAgICB8fCAoU2VydmVySGVsbG8uc2VydmVyX3ZlcnNp b24gJiB+UEFUQ0hFRF9SRU5FR09fRkxBRykgPj0gVExTdjEzICkgew0KICAgICAgcy0+dXNlX3Nl Y3VyZV9yZW5lZ290aWF0aW9uID0gVFJVRTsNCiAgIH0NCg0KU28gaXQgaXMgYSB2ZXJ5IGdvb2Qg YW5kIHRoZSBtb3N0IG5hdHVyYWwgcGxhY2UuDQoNCldlIGFyZSBkZWZpbml0ZWx5IGNoYW5naW5n IGFuIGVzc2VudGlhbCBwYXJ0IG9mIHRoZSBwcm90b2NvbC4NCkJ1dCB3ZSBhcmUgYWxzbyBjaGFu Z2luZyBpdCBvcnRob2dvbmFsIHRvIHJlZ3VsYXIgVExTLXZlcnNpb25pbmcsDQppLmUuIHdlcmUg X05PVF8gY3JlYXRpbmcgVExTdjEuMywgYnV0IGluc3RlYWQgd2UgYXJlIGNyZWF0aW5nDQptb2Rp ZmllZCBwcm90b2NvbCB2ZXJzaW9ucyBvZiAgU1NMdjMsIFRMU3YxLjAsIFRMU3YxLjEgYW5kIFRM U3YxLjINCg0KDQpXaGF0IGV4YWN0bHkgaXMgeW91IHByb2JsZW0gd2l0aCBzYWNyaWZpY2luZyBh IGJpdCBvZiB0aGUNCnNlcnZlcl92ZXJzaW9uIG5ldHdvcmsgZW5jb2RpbmcoISkgaW4gb3JkZXIg dG8gc2lnbmFsIGEgcHJvdG9jb2wNCmNoYW5nZSB0aGF0IGlzIG9ydGhvZ29uYWwgdG8gVExTIHBy b3RvY29sIHZlcnNpb25pbmc/DQoNCg0KLU1hcnRpbg0K From rrelyea@redhat.com Wed Nov 18 14:29:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1D73A6AA3 for ; Wed, 18 Nov 2009 14:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 c6FI5UNIVQZo for ; Wed, 18 Nov 2009 14:29:25 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 63BBA3A6A24 for ; Wed, 18 Nov 2009 14:29:25 -0800 (PST) Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAIMIpl5015707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Nov 2009 17:18:51 -0500 Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAIMImdq027077; Wed, 18 Nov 2009 17:18:49 -0500 Message-ID: <4B0472C8.5040306@REDHAT.COM> Date: Wed, 18 Nov 2009 14:18:48 -0800 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: mrex@sap.com References: <200911181910.nAIJAe26011062@fs4113.wdf.sap.corp> In-Reply-To: <200911181910.nAIJAe26011062@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.97a Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020109090903030806020301" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.18 Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 22:29:26 -0000 This is a cryptographically signed message in MIME format. --------------ms020109090903030806020301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/18/2009 11:10 AM, Martin Rex wrote: > Nelson B Bolyard wrote: > =20 >> =20 >>> This would be extremely simple to implement, >>> =20 >> This is going to be a LOT more code for me (for NSS) than RI was becau= se >> it means this new magic number must be special cased EVERYWHERE that c= ipher >> suite numbers are handled. The code must ensure that the local applic= ation >> cannot enable it or disable it. The code must not report it as a supp= orted >> cipher suite to the local application. The code that checks every cip= her >> suite to see that the necessary crypto algorithms, certs and keys for = it >> are locally present must not perform those checks for this cipher suit= e. >> The code must ensure at both ends that this suite number never gets >> negotiated. The work to do this is not particularly difficult or comp= lex. >> It's just a lot of code strewn all over. >> =20 > How about approaching this from a different angle. You seem > to be several software layer above where this change should go. > > > The TLS client should add that special ciphersuite ID when composing > the ClientHello handshake message. This is _NOT_ intended to be > something configurable to applications through regular ciphersuite > selections. > =20 What bothers me about this whole line of reasoning is we are abusing well defined fields to work around the fact that some implementations do not support the standard way of extending (that is extensions). I see this as wrong because: 1) We already need to use extensions to get other important features in TLS (the most notable is SNI). 2) This rewards people who have blatantly ignored the spec --- for years. (the use of extensions is not new. People have had close to a decade to fix their issues). 3) We are depending on friendly behavior from toolkits that cannot correctly implement 'ignore anything after this byte' in the spec. 4) Well structured code is designed to handle extensions. Repurposing fields will almost certainly punish well structured code. Clients have already developed solutions so they can use extensions in our ecosystem. Cleaning out servers that cannot handle them by marking them as insecure is a good thing. In short this proposal rewards bad implementations and rewards good ones.= bob --------------ms020109090903030806020301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV7DCC Bv8wggXnoAMCAQICAwCrKTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MTAxNDAwMDAwMVoXDTEwMTAxNDIwNTQyMVowbjEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9dBmw8V94Rx84iwE5RpiO+uHKS5e91CHnKf JsbEOzPxS7Hgizt78ratBbhkudQ7bJIH1o9nh0Q5c/LdOlWUF1Jn+3+JNGvs6h/vlmfCYGPK TZpUbwPm8Rmik+bDNlAOUkDieZHfUg8HOdGrqvp1prqqwLMzgovi5YiETf28SO9kxNqjkbBL VxsBlHrnjG1dmn8jAYZ1XPctXMEsHV+2EISDOPYWl/CE2jt7km6Hkxq7D6p/z8Ef9Zn/uZ1z onthvoDp+BJOIIa6s68r9rLGNtAQ5/OtxXKpk6Cz5SAUgZIo0p2tNyQ2hFy8ojUZm2hNKVfu 6lN9DcSU0sri8I0S1QIDAQABo4IDhTCCA4EwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6fisKv/TEZ8c96u/L+x4d RtrwdjCBqAYDVR0jBIGgMIGdgBRTcu2SnODaywFcfH6WNU7y1LhRgqGBgaR/MH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eYIBDTAdBgNVHREEFjAUgRJycmVseWVhQHJlZGhhdC5jb20wggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNz bC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRk LjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8E XDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAOBrTD2DJvI0rP6phlUjV0JU6owP2XLQ2fZZ42J LHqfJ+yJWqpprzbHK7c7oJjy/TlNUQzFQZvtQM0WAcopsOzvqeXyB9lt6Zqq1ULMG9s5yMM0 rq/dpYFE2ju9WY8+7962iSkqGmMwrq9ZwO8J37zmMDS3ifw3/n3/Ns1t7MK6tanzkugScuW9 TQr/zQNNanLQmeuvU6Fbru6UFZI6c1qW0G4B1ptfTEQiAQ+E7PdIdjI9SYd24uU6/OdPlGrV tgl0UUnwLuCwA+D84xtc4+TjkLFxuqKCTi0NDONzosPzrNGJ7Kcau5bqV5AUxVz6bUifqQ3a X7xgD7Vq0EGCCK4wggb/MIIF56ADAgECAgMAqykwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0wOTEwMTQwMDAwMDFaFw0xMDEwMTQyMDU0 MjFaMG4xHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVk aGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfXQZsPFfeEcfOIsBOU aYjvrhykuXvdQh5ynybGxDsz8Uux4Is7e/K2rQW4ZLnUO2ySB9aPZ4dEOXPy3TpVlBdSZ/t/ iTRr7Oof75ZnwmBjyk2aVG8D5vEZopPmwzZQDlJA4nmR31IPBznRq6r6daa6qsCzM4KL4uWI hE39vEjvZMTao5GwS1cbAZR654xtXZp/IwGGdVz3LVzBLB1fthCEgzj2FpfwhNo7e5Juh5Ma uw+qf8/BH/WZ/7mdc6J7Yb6A6fgSTiCGurOvK/ayxjbQEOfzrcVyqZOgs+UgFIGSKNKdrTck NoRcvKI1GZtoTSlX7upTfQ3ElNLK4vCNEtUCAwEAAaOCA4UwggOBMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+n4r Cr/0xGfHPervy/seHUba8HYwgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKh gYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQu Y29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQW DVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEt Y3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADga0w9gybyNKz+qYZVI1d CVOqMD9ly0Nn2WeNiSx6nyfsiVqqaa82xyu3O6CY8v05TVEMxUGb7UDNFgHKKbDs76nl8gfZ bemaqtVCzBvbOcjDNK6v3aWBRNo7vVmPPu/etokpKhpjMK6vWcDvCd+85jA0t4n8N/59/zbN bezCurWp85LoEnLlvU0K/80DTWpy0Jnrr1OhW67ulBWSOnNaltBuAdabX0xEIgEPhOz3SHYy PUmHduLlOvznT5Rq1bYJdFFJ8C7gsAPg/OMbXOPk45Cxcbqigk4tDQzjc6LD86zRieynGruW 6leQFMVc+m1In6kN2l+8YA+1atBBggiuMIIH4jCCBcqgAwIBAgIBDTANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGB pH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkw VzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w b2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0 ZXMwDQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP /4H/Bc8FFDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhp cqMr3OyzK3aYGJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyR WTTX6mWSv+TraOwuj3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNh HeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG8 59MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6Gu UcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf 6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIO uAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdC taW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/TyxV/stlehMYID0DCC A8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMAkGBSsO AwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5 MTExODIyMTg0OFowIwYJKoZIhvcNAQkEMRYEFO5HZ+zATaJ8TiZPKhpex6QN+yWWMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBABD6LhjB5b2VZY/4pU+4Ejyiqvj6YSTGZliAFPmpSJDVM+fsaoFe jzGHjV6vmHB2BfDXBnJasbesORJPoyt5a3kyg4b3k6WZ8t/q8Ui54jLJezwmyeSQBbQaWGQt 1/wo52Q+sUIN27m5NPwhZdL/h2w/Ko/A5TUkFx4wFPetRUQz+0m8wL5XZTaIm4QsJuN1EuP4 Kc1X4dVQsbKIpkGYpYn1OmqPmBaXN3m/ZAO/F1TsOZ4xM4nIUJwVopXcxhfrplTBfQZ93GIm GoP1CwoqRKMawFnFLtbnq4DyB+M7qpdjt/3iV5gaxXjYm737yc5VcI8W3Ft8LBxizLcSEBm8 HVQAAAAAAAA= --------------ms020109090903030806020301-- From mrex@sap.com Wed Nov 18 14:49:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13763A6ADE for ; Wed, 18 Nov 2009 14:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.055 X-Spam-Level: X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=0.194, 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 k3nxdChdsNrL for ; Wed, 18 Nov 2009 14:49:36 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 946BF3A69C0 for ; Wed, 18 Nov 2009 14:49:36 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAIMnXur017344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 23:49:33 +0100 (MET) From: Martin Rex Message-Id: <200911182249.nAIMnW4e023915@fs4113.wdf.sap.corp> To: uri@ll.mit.edu (Blumenthal Uri - 0662 - MITLL) Date: Wed, 18 Nov 2009 23:49:32 +0100 (MET) In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3E6@LLE2K7-BE01.mitll.ad.local> from "Blumenthal, Uri - 0662 - MITLL" at Nov 18, 9 04:57:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 22:49:37 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > > Is it the only viable solution??? I am open to suggestions and improvements. It is the best one that _I_ have found in the SSLv3/TLSv1.0 ServerHello PDU (there are not that much elements to choose from). Since this signal is security relevant, *I* strongly prefer that old servers are extremely unlikely to create this value by accident. > > I am concerned of "overloading" fields and assigning an additional > meaning to them that they did not have. Not a clean design or > programming practice, and prone to causing people or code used > to the "old" meaning to stumble. In principle, I tend to agree. However, we are actually changing several past revisions of a protocol in a significant and purposely non-interoperable fashion -- because that interoperability turned out to be a security problem. I will try to provide sufficiently clear guidance to implementors what this particular change means -- and only code which implements the fix will ever be confronted with this changed semantics that should _only_ be visible in the network transfer encoding. It is really just method to compress an extra bit of information representing a protocal change orthogonal to existing protocol versions into the network transfer encoding of the server_version element in the ServerHello PDU. -Martin From mike-list@pobox.com Wed Nov 18 15:05:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB883A68FF for ; Wed, 18 Nov 2009 15:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 42fbGsD6k4Vp for ; Wed, 18 Nov 2009 15:05:58 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id F07753A6991 for ; Wed, 18 Nov 2009 15:05:57 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B32939FDA8 for ; Wed, 18 Nov 2009 18:05:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=AFj0OvlunCBb wu0yeuk4BJNRseM=; b=puvmp72lEUjwjkRC2FwEgXwQky24I+LOxUpFLJYyPfOt qGemyUSNdhgyYFQQgDmWRXZnktPn6OMpjIF8oI5N7mRezAWVyVE9EdhRMHlkO+Vn my15+6Hx6AcPmvQU+1Dnd68npjtJHvGi7dbl/aoQlmi4BkMHq6gpQ2J+zOW/8aI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=KcTfrJ NzYojQJFmcE5QfZcxZT4HwaAckX++P63qLPl5c4c9FBumTYQWGgkM5p/Aub9Q2n6 G730hb4qFU+LV4RrkdL8NGg/n3CVun5jPlp0yPTbMpIm5p4EFPvoXo7JSDXmuYcg u0EW74ys4rsrkqsx74Upr2w5uox49NiBojJBM= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B01499FDA6 for ; Wed, 18 Nov 2009 18:05:55 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 648FA9FDA5 for ; Wed, 18 Nov 2009 18:05:55 -0500 (EST) Message-ID: <4B047E1D.7090401@pobox.com> Date: Wed, 18 Nov 2009 15:07:09 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911181910.nAIJAe26011062@fs4113.wdf.sap.corp> In-Reply-To: <200911181910.nAIJAe26011062@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: ED29278A-D496-11DE-940C-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:05:59 -0000 Martin Rex wrote: > Nelson B Bolyard wrote: >> On 2009-11-18 06:57 PST, Pasi.Eronen@nokia.com wrote: >>> Hmm... not all clients today support renegotiation, and IMHO the fix >>> should be especially simple to deploy for those clients. Those clients >>> could just include a magic cipher suite number in all client hellos, >>> meaning "this is not a renegotiation". >> >>> This would be extremely simple to implement, >> This is going to be a LOT more code for me (for NSS) than RI was ...... > > How about approaching this from a different angle. You seem > to be several software layer above where this change should go. > > The TLS client should add that special ciphersuite ID when composing > the ClientHello handshake message. This is _NOT_ intended to be > something configurable to applications through regular ciphersuite > selections. That is how I implemented it in my code. There is no configuration to turn it off, since that would be unnecessary. The code that creates the ClientHello simply prepends the special ciphersuite to the list. > On the TLS server, the code that parses the ServerHello should > recognize this special ciphersuite ID, convert it into a > seperate state variable in the securityparameters of the connection state > and _NOT_ pass it up to software layers above or even higher to > applications between real ciphersuite IDs. And I did this too. The code that parses the client's list of cipher suites looks for the special value and sets a flag when it sees it. It is not put in the list of ciphers passed to the cipher suite selection code. Mike From mike-list@pobox.com Wed Nov 18 15:16:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832C33A677D for ; Wed, 18 Nov 2009 15:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 1wabGi1SwUtY for ; Wed, 18 Nov 2009 15:16:40 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 120843A6A28 for ; Wed, 18 Nov 2009 15:16:38 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 30FCA9FE5B for ; Wed, 18 Nov 2009 18:16:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=RvS9QxtOujlS T0mIDrg4WV3z0eU=; b=OARspWcZnYnpKkhnfCTZXMaSCKwvZmyvmh4NItqh1ItV Mour0owFsNSI2JmTZiBWGKdQS+fSdbnxsAmQmsNZbfVoOB0Qhs1yUYq8tdDCQhth cJV7Gu1O3F7sCJrzj9pcKYWdEjw3YH2qtJKzoh7u457flSAEUOvSIbinebnUDD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=SYFn3k 3yNSf89Vl8NytzV9/gX/zclzjeD8T/daYp7IfLcaabBLSQlt4xY4S/tgrIFrSL8E /zgsFNlis4k374lHO9npRbtXXFd+sawA1pucgs7yMXQ1tyhWyWdMB7ikYF6m1LfG aLZLp5XNdRc8F0d/XlXU8MU8I+1l37rgOyX3s= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 2DB239FE5A for ; Wed, 18 Nov 2009 18:16:37 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id BE4DA9FE59 for ; Wed, 18 Nov 2009 18:16:36 -0500 (EST) Message-ID: <4B04809F.20405@pobox.com> Date: Wed, 18 Nov 2009 15:17:51 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3E6@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3E6@LLE2K7-BE01.mitll.ad.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 6B814F44-D498-11DE-B2DA-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:16:41 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > I am concerned of "overloading" fields and assigning an additional > meaning to them that they did not have. Not a clean design or > programming practice, and prone to causing people or code used to > the "old" meaning to stumble. The client will still only send the versions used today. It is only when the server sees the magic cipher suite that it flips one bit in the server version returned to the client. Unpatched clients will not send the special cipher suite, so they will not be confused. Also the version used in the record layer would not change as a result (you mask off the bit when setting it). > Is it the only viable solution??? It is 100% reliable. Using the server random allows for a small possibility of an unpatched server randomly generating whatever signal we come up with. I don't think it would be wise to try to use the returned cipher suite or compression method. The session ID is limited to 32 bytes, but in theory it could be up to 255, so it would be possible to do something there, though it seems dangerous. I prefer using a single bit in the version. Those are the only fields in the SSLv3 ServerHello. Mike > ----- Original Message ----- > From: Martin Rex > To: Blumenthal, Uri - 0662 - MITLL > Cc: tls@ietf.org > Sent: Wed Nov 18 16:42:43 2009 > Subject: Re: [TLS] TLS Protocol Version > > Blumenthal, Uri - 0662 - MITLL wrote: >> After following this discussion for a while, I can say that I too >> am against fooling around with protocol version number >> (or with re-purposing an existing field). A clean extension-based >> solution is what's needed. And if SSLv3 can't/won't support it - so be it. > > This is definitely not about fooling around. > It is strictly about compressing the information in the > ServerHello.server_version field while it travels the network > in a fashion that the client will understand perfectly well. > > I expect that we will want to make the protected renegotiation > part of the TLSv1.3 base spec, and will prohibit the use of the > unprotected TLS renegotiation if the protocol version TLSv1.3 > is negotiated. > > So it is actually the exact same position in the client code > (parsing of ServerHello) that will decide when secure renegotiation > is used there. > > if ( 0!=(ServerHello.server_version & PATCHED_RENEGO_FLAG) ) > || (ServerHello.server_version & ~PATCHED_RENEGO_FLAG) >= TLSv13 ) { > s->use_secure_renegotiation = TRUE; > } > > So it is a very good and the most natural place. > > We are definitely changing an essential part of the protocol. > But we are also changing it orthogonal to regular TLS-versioning, > i.e. were _NOT_ creating TLSv1.3, but instead we are creating > modified protocol versions of SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2 > > > What exactly is you problem with sacrificing a bit of the > server_version network encoding(!) in order to signal a protocol > change that is orthogonal to TLS protocol versioning? > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From djhopwood@googlemail.com Wed Nov 18 15:24:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199A628C133 for ; Wed, 18 Nov 2009 15:24:33 -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 YWcYqZF0cnTa for ; Wed, 18 Nov 2009 15:24:32 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id A0C833A6A05 for ; Wed, 18 Nov 2009 15:24:29 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so321136eya.51 for ; Wed, 18 Nov 2009 15:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=/jZ/zjtvG4hiaatT/r+2i1UV4hE5g46bw8tpoMKPSIc=; b=o4iDvKIxsvhvT2cP638iLvsACQwy+TYMq6KdDtya+0qcIZxfqU5xqFewQeoLliUDT+ zNM24krK+FC8XB+Guf0gk9QqIDDtTkud9UyeUxtTanJ0Fp9JOLi46roecKmbdZS7X0UF nVhNDJ2F4TsMvntvQVrTRwdiIe8YHZofGK+iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=v+Z41JhkmAMHe14YD+86/QD+OO21lAPmsqJmyP0mwe7zMdodWPtDC5zJgWeZFkpKD6 9Ple1RlF0ieGled6apjT2wJ8K1hMtyGAiy122PlGenu0CLMgJxlR6OrxFC/smQL0mlPk Wm/uYAXEv7fsHdpl+O3RbiZH/+hXAcmFlBnyo= Received: by 10.213.97.22 with SMTP id j22mr2897521ebn.53.1258586664353; Wed, 18 Nov 2009 15:24:24 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm144623ewy.12.2009.11.18.15.24.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 15:24:23 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B048226.6090306@jacaranda.org> Date: Wed, 18 Nov 2009 23:24:22 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4d2fac900911151445v69f84638n11bb9d6525d381ea@mail.gmail.com> <4B012BA3.1040803@opera.com> <66336217-4343-40D2-9E06-6A8C5311686A@apple.com> <88C981CF-1088-4BF8-9767-858362E6D710@mozilla.org> <36424A04-1CA9-44FB-A94D-ABC1F411894F@mozilla.org> <945055E2-FF30-490C-9DB1-DA16C2AED522@apple.com> <2B42655D-2E27-459A-AE5E-8223A8894A38@apple.com> <4B03816A.5080302@jacaranda.org> In-Reply-To: <4B03816A.5080302@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigAFC286AF88F1064AA702CE44" Subject: Re: [TLS] Conflicts between W3C specs and ES5? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:24:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAFC286AF88F1064AA702CE44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oops, wrong mailing list. Sorry about that. David-Sarah Hopwood wrote: > Brendan Eich wrote: >> On Nov 17, 2009, at 6:41 PM, Maciej Stachowiak wrote: >> >>>>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws > [...] >>>> What is the rationale for throwing in this last case, rather than >>>> using the explicit base object (otherWindow) as |this|? > [...] >> The standard ECMA-262 semantics want otherWindow -- "bound method" >> exceptions prove the rule. >=20 > There are bound methods in ES implementations? I'm all ears. >=20 >=20 > (One thing I've never understood is why ES implementors add features > or exceptional behaviour that users of the language could only find, > or even know to look for, by reverse engineering or guesswork. What's > the point? Doesn't it take more work to add all this stuff?) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigAFC286AF88F1064AA702CE44 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksEgjEACgkQWUc8YzyzqAcyrwD+NYfvW/E+yOu/5PZ/D5T8sVdl xnNlysWBXPBsCz/C0D8A/i3aA8DDFJAet/Z5SfbMXULR/24RLZH0e2Q1sxD5Ataw =AMFe -----END PGP SIGNATURE----- --------------enigAFC286AF88F1064AA702CE44-- From djhopwood@googlemail.com Wed Nov 18 15:30:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E5528C133 for ; Wed, 18 Nov 2009 15:30:11 -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 LesFUa-9MxMx for ; Wed, 18 Nov 2009 15:30:10 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 1F35D28C144 for ; Wed, 18 Nov 2009 15:30:09 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so322556eya.51 for ; Wed, 18 Nov 2009 15:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=1TGZxSl7qEFIgbtayThO9YsAD2gCGoUwjRB3T4VSbjA=; b=Q+Q/gB0LcLkXyvRrapknKVvgF6rKO+8fRg4kax2q8MY2YOzk4LXvDS/gXEfSoCyz5z zO5ESH60349ownyXAYc9hs1++nADxyMfUQXqgFtUzVYRQeXOszpEpwh0zesVoxg4oOdm rlbOZp6fFH12xxXJohmAEopgn3n51tqf3sflc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=KUshgowEYSo4Oki7XflKKPY+SOE8XKbgInrnofKAPoN2bs3PhH0kmoqIEhRkOPy8Zh S1jd3+24Q2XvVl1jYC65oY+DghI8z5/4+0qZ/OgYInZv0DFqm7vQOuJ3WGHCEZLygElc WCpdOvPUXBLD6JKpkzdrkal1RWawK8J/8V5pw= Received: by 10.213.0.218 with SMTP id 26mr720185ebc.19.1258587003278; Wed, 18 Nov 2009 15:30:03 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm146074ewy.12.2009.11.18.15.30.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 15:30:02 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B048383.5010605@jacaranda.org> Date: Wed, 18 Nov 2009 23:30:11 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> <808FD6E27AD4884E94820BC333B2DB774F30FE105B@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE105B@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE428C22FEAA9CAB8AC860BAD" Subject: Re: [TLS] user requirements for TLS fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:30:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE428C22FEAA9CAB8AC860BAD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pasi.Eronen@nokia.com wrote: > Chris Newman wrote: >=20 >> As a power user, I want two settings for my all my TLS clients ASAP: >> >> 1. treat unpatched servers as if SSL/TLS was not being used with >> respect to security indicators in the UI; but otherwise continue >> with connection. >> >> 2. Warn when contacting an unpatched server giving me the option to >> abort the transaction (and even better if it won't bother me for a >> month or so if I choose to continue). >> >> I will use option 1 most of the time initially and will switch to >> option 2 when the time is right (maybe a year or so?). >=20 > This seems to be confusing "unpatched" (*) with "vulnerable". Since "unpatched" cannot be reliably or efficiently distinguished from "vulnerable", then there is no choice but to treat them the same, in respect of UI indicators or anything else. > But servers that never allowed renegotiation to begin with are not > vulnerable, and many others can just disable renegotiation (without > implementing anything else). These servers won't have any need > to patch, and will be around "unpatched" much longer than a year=20 > from now. All servers, regardless of their vulnerability, will have to patch if they are to remain interoperable with strict clients. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigE428C22FEAA9CAB8AC860BAD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksEg4MACgkQWUc8YzyzqAdIQAD6AnMjsI4F+3rE3CkrTZmUiLVs izsqYTtxAk3mm0W2s6EA/0dbBRWgp/XZyOd6Yimd5rD/hKLdm4Be0g5BNg1NX1dG =Lf77 -----END PGP SIGNATURE----- --------------enigE428C22FEAA9CAB8AC860BAD-- From noskov@microsoft.com Wed Nov 18 15:45:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F27828C15A for ; Wed, 18 Nov 2009 15:45:00 -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 lDdhK56yLdsk for ; Wed, 18 Nov 2009 15:44:59 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id E07C928C144 for ; Wed, 18 Nov 2009 15:44:58 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 Nov 2009 15:45:18 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server id 14.0.639.20; Wed, 18 Nov 2009 15:44:56 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 18 Nov 2009 15:44:55 -0800 From: Nasko Oskov To: "tls@ietf.org" Thread-Topic: Proposal for hybrid solution using most of the ideas Thread-Index: AcpoqOAR5flNsc7xQSS4tqrARn2pVg== Date: Wed, 18 Nov 2009 23:43:05 +0000 Deferred-Delivery: Wed, 18 Nov 2009 23:44:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BFIP CbFc DY++ Dtno EXAa E5PU FKKh FUNL FmmD GYoG HRB4 IuoD I2Wr KF8b KZFW KfJT; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {F16959C9-C39E-4723-9E49-EE44B1172C86}; bgBvAHMAawBvAHYAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Wed, 18 Nov 2009 23:44:00 GMT; UAByAG8AcABvAHMAYQBsACAAZgBvAHIAIABoAHkAYgByAGkAZAAgAHMAbwBsAHUAdABpAG8AbgAgAHUAcwBpAG4AZwAgAG0AbwBzAHQAIABvAGYAIAB0AGgAZQAgAGkAZABlAGEAcwA= x-cr-puzzleid: {F16959C9-C39E-4723-9E49-EE44B1172C86} Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:45:00 -0000 Currently, many browsers attempt to negotiate TLS with extensions, but if i= t fails for any reason, they re-start the negotiation without extensions (e= ither as a TLS negotiation or an SSLv2/3) negotiation. That behavior leads = to a trivial downgrade attack by a MiTM - all the MiTM has to do is fail an= y negotiation with the renegotiation extension present and wait for the bro= wser to try a negotiation without it. This leads to situation where the cli= ent is unaware if there is MiTM or real server that doesn't support extensi= ons. If we want browsers to be secure we have no choice but fixing SSLv3 so= mehow or disabling it entirely. I've been reading all the ideas people have come up with and there are some= good suggestions in all the mails exchanged. After discussing the various = approaches with Paul Leach and passing some ideas around with Marsh Ray, we= came up with a blended approach to solving the overall problem. I would li= ke to propose a solution that uses some of the ideas brought up.=20 We all agree that there are two parts to the solution - signaling and chang= ing state to allow for detection of the attack (aka cryptographically bindi= ng the two handshakes), so the general spirit is to use single way of chang= ing state and different signaling for TLS and SSLv3. For SSLv3, we can use the cipher suite idea and define the magic cipher sui= te value that SSLv3 client will send out to the server. Based on this indic= ator, server knows whether to use regular running hash as it is today or us= e the modified running hash. The problem for SSLv3 is the signal from the s= erver to the client. S->C signaling must be done in a handshake message pre= ceding the Finish message, so both client and server can agree on the versi= on of the running hash. The one dynamic field we know from experience is ha= ndled properly by implementations is the list of certificates. We can use t= he server Certificate message as the signal by including specially defined = certificate in the list of certificates sent by the server. If the server s= ees the magic cipher suite, the special certificate is included at the end = of the certs being sent. We can define the cert to be the smallest possible= server (aka very little real data in it) and include an unique OID to ensu= re we don't collide with some real usage of "empty" certificate. Here is the matrix for interop: Old server New server ---------------------------------------------------------------------------= - Old Client | as is | server detects old client on=20 | | ClientHello and can interop=20 | | based on config | | =20 ---------------------------------------------------------------------------= - New Client | detects old server | server detects new client on=20 | on Certificate message and | initial handshake =20 | can interop based on config | client detects new server on=20 | | Certificate | | both start using the modified=20 | | running hash ---------------------------------------------------------------------------= - There are few ways the running hash can be modified and it seems inserting = the previous Finished message into the running hash is something everyone a= grees should work. Inserting it as the initial input to the new running has= h is a clean approach and allows for easier logic. The only drawback is tha= t the SSLv3 client will have to keep two hash states around until the Certi= ficate message is received, but the client needs to keep the ClientHello ar= ound until the ServerHello is received back, so the complexity should not b= e much greater. For TLS 1.0 and above, we can use this same approach with very little modif= ication. Since we have clear signaling in the Hello messages using extensio= ns, both client and server can detect unpatched parties and based on config= either proceed or terminate. The major difference is that TLS client doesn= 't have to maintain two different hash states, since server signals the cli= ent and the client can make the decision whether to hash the previous Finis= hed message into the running hash or not. As such, the extension as propose= d today does not need to transmit the actual Finished messages, as they wil= l be cached on each end.=20 Overall what we achieve is: * modifying the running hash only for renegotiations, which allows interop = for cases where renego is not needed (a big portion of the traffic) * clear signaling in TLS implementations * backwards compatible solution for SSLv3 * both sides can interop or not with unpatched parties based on configurati= on * even if both sides are lenient in behavior, they are secure as long as bo= th of them are patched * clients falling back from TLS to SSLv3 because of extensions compatibilit= y will be safe Alternatively, we can use the existing draft for TLS and the proposed solut= ion here for SSLv3. Nasko P.S. The extension will have to be a "MUST" for all TLS implementations, ot= herwise the MiTM can downgrade to TLS without extensions and we are back at= having the problem. This requires, among other things, that browser fallba= ck logic be slightly changed. There should not be a case of sending a TLS C= lientHello without the extension. If the server reacts poorly, a downgrade = directly to SSLv3 plus the signaling solution should be attempted. From pgut001@wintermute01.cs.auckland.ac.nz Wed Nov 18 16:14:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBC13A677D for ; Wed, 18 Nov 2009 16:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.359 X-Spam-Level: X-Spam-Status: No, score=-4.359 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751] 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 27vAHtwfExgD for ; Wed, 18 Nov 2009 16:14:49 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 3957D3A6A38 for ; Wed, 18 Nov 2009 16:14:43 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0F38219D51; Thu, 19 Nov 2009 13:14:38 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2B-VUAxh2N5; Thu, 19 Nov 2009 13:14:37 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3B8BB19CF3; Thu, 19 Nov 2009 13:14:37 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAufV-0000Sr-GJ; Thu, 19 Nov 2009 13:14:37 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NAufV-0004tl-0F; Thu, 19 Nov 2009 13:14:37 +1300 From: Peter Gutmann To: tls@ietf.org, uri@ll.mit.edu In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3E3@LLE2K7-BE01.mitll.ad.local> Message-Id: Sender: pgut001 Date: Thu, 19 Nov 2009 13:14:37 +1300 Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 00:14:50 -0000 "Blumenthal, Uri - 0662 - MITLL" writes: >After following this discussion for a while, I can say that I too am against >fooling around with protocol version number (or with re-purposing an existing >field). A clean extension-based solution is what's needed. And if SSLv3 >can't/won't support it - so be it. I've kept quiet so far but I have to venture an opinion at this point: having followed the massive amount of information exchanged so far, I think the magic-cipher-suite + modified-finished is far, far cleaner than the extension Russian roulette option. Peter. From mike-list@pobox.com Wed Nov 18 16:14:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37793A694E for ; Wed, 18 Nov 2009 16:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 43yxBBofVxbg for ; Wed, 18 Nov 2009 16:14:49 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 85A153A6886 for ; Wed, 18 Nov 2009 16:14:46 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5BE0080337 for ; Wed, 18 Nov 2009 19:14:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=4PfkBddVFPj9 MwhkZDWow10FgVE=; b=i9wINNjK0dtW6zSu7BLfaan/VpRuqB2eHtKcDvg1M4wG lkkZtDYaCEdLF0LokFERTP+AsJhkvRZtlsmLBGLU+b6fnRoZewx9TgzPE33Q1/ud OnozTRXHMp7v86l5P0S6A/uNK7oa0TVG8rz50xsdcl+i9zMwM2aBLxFuPDw7X3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=DdTNj0 CCTmJD7vOVx2LET8WMnXCth6nD+NqjK4E+WKHt0ni2PluX94CCBpFKOJtKkx5hQw Hdl495wY/BmkZ5vsC1MF7ma73Q2wVmnVshFBoO7aRprNbbyRY8MEgrGcu3maFfxF e/b/9POPijq/+UyYpfwVyE+sGiJM9UjaMSKig= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 55D4A80336 for ; Wed, 18 Nov 2009 19:14:42 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id EBB9C80335 for ; Wed, 18 Nov 2009 19:14:40 -0500 (EST) Message-ID: <4B048E3B.2010506@pobox.com> Date: Wed, 18 Nov 2009 16:15:55 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 88D47938-D4A0-11DE-AF5E-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 00:14:51 -0000 So you want to have two solutions, one for TLS 1.0+ and another for SSLv3? I'm not sure why we need two when any solution that works for SSL will also work for TLS. Also the Certificate message is optional, so it would cause trouble for some cipher suites. And even more importantly, there is only ServerHello sent when you resume an old session! Mike Nasko Oskov wrote: > Currently, many browsers attempt to negotiate TLS with extensions, but if it fails for any reason, they re-start the negotiation without extensions (either as a TLS negotiation or an SSLv2/3) negotiation. That behavior leads to a trivial downgrade attack by a MiTM - all the MiTM has to do is fail any negotiation with the renegotiation extension present and wait for the browser to try a negotiation without it. This leads to situation where the client is unaware if there is MiTM or real server that doesn't support extensions. If we want browsers to be secure we have no choice but fixing SSLv3 somehow or disabling it entirely. > > I've been reading all the ideas people have come up with and there are some good suggestions in all the mails exchanged. After discussing the various approaches with Paul Leach and passing some ideas around with Marsh Ray, we came up with a blended approach to solving the overall problem. I would like to propose a solution that uses some of the ideas brought up. > We all agree that there are two parts to the solution - signaling and changing state to allow for detection of the attack (aka cryptographically binding the two handshakes), so the general spirit is to use single way of changing state and different signaling for TLS and SSLv3. > > For SSLv3, we can use the cipher suite idea and define the magic cipher suite value that SSLv3 client will send out to the server. Based on this indicator, server knows whether to use regular running hash as it is today or use the modified running hash. The problem for SSLv3 is the signal from the server to the client. S->C signaling must be done in a handshake message preceding the Finish message, so both client and server can agree on the version of the running hash. The one dynamic field we know from experience is handled properly by implementations is the list of certificates. We can use the server Certificate message as the signal by including specially defined certificate in the list of certificates sent by the server. If the server sees the magic cipher suite, the special certificate is included at the end of the certs being sent. We can define the cert to be the smallest possible server (aka very little real data in it) and include an unique OID to ensure we don't c ol > lide with some real usage of "empty" certificate. > > Here is the matrix for interop: > > Old server New server > ---------------------------------------------------------------------------- > Old Client | as is | server detects old client on > | | ClientHello and can interop > | | based on config > | | > ---------------------------------------------------------------------------- > New Client | detects old server | server detects new client on > | on Certificate message and | initial handshake > | can interop based on config | client detects new server on > | | Certificate > | | both start using the modified > | | running hash > ---------------------------------------------------------------------------- > > There are few ways the running hash can be modified and it seems inserting the previous Finished message into the running hash is something everyone agrees should work. Inserting it as the initial input to the new running hash is a clean approach and allows for easier logic. The only drawback is that the SSLv3 client will have to keep two hash states around until the Certificate message is received, but the client needs to keep the ClientHello around until the ServerHello is received back, so the complexity should not be much greater. > > For TLS 1.0 and above, we can use this same approach with very little modification. Since we have clear signaling in the Hello messages using extensions, both client and server can detect unpatched parties and based on config either proceed or terminate. The major difference is that TLS client doesn't have to maintain two different hash states, since server signals the client and the client can make the decision whether to hash the previous Finished message into the running hash or not. As such, the extension as proposed today does not need to transmit the actual Finished messages, as they will be cached on each end. > > Overall what we achieve is: > * modifying the running hash only for renegotiations, which allows interop for cases where renego is not needed (a big portion of the traffic) > * clear signaling in TLS implementations > * backwards compatible solution for SSLv3 > * both sides can interop or not with unpatched parties based on configuration > * even if both sides are lenient in behavior, they are secure as long as both of them are patched > * clients falling back from TLS to SSLv3 because of extensions compatibility will be safe > > Alternatively, we can use the existing draft for TLS and the proposed solution here for SSLv3. > > Nasko > > P.S. The extension will have to be a "MUST" for all TLS implementations, otherwise the MiTM can downgrade to TLS without extensions and we are back at having the problem. This requires, among other things, that browser fallback logic be slightly changed. There should not be a case of sending a TLS ClientHello without the extension. If the server reacts poorly, a downgrade directly to SSLv3 plus the signaling solution should be attempted. From pgut001@wintermute01.cs.auckland.ac.nz Wed Nov 18 16:23:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3943A6886 for ; Wed, 18 Nov 2009 16:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.479 X-Spam-Level: X-Spam-Status: No, score=-5.479 tagged_above=-999 required=5 tests=[AWL=1.120, 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 z9Si36f31+os for ; Wed, 18 Nov 2009 16:22:59 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 6F8483A657C for ; Wed, 18 Nov 2009 16:22:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4554719D79; Thu, 19 Nov 2009 13:22:55 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZruMP7e4zrJ; Thu, 19 Nov 2009 13:22:38 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B773419D85; Thu, 19 Nov 2009 13:22:38 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAunG-0000qw-IP; Thu, 19 Nov 2009 13:22:38 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NAunG-0005fo-Ia; Thu, 19 Nov 2009 13:22:38 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <200911181423.nAIENne8023747@fs4113.wdf.sap.corp> Message-Id: Sender: pgut001 Date: Thu, 19 Nov 2009 13:22:38 +1300 Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 00:23:00 -0000 Martin Rex writes: >If you are referring to the SSLv2 backwards-compatibility option, that seems >to be actually still used in Firefox 3.5 in the automatic reconnect fallback >should the server choke on TLS extensions. The last time I checked it was *always* used, not just as a fallback option. In other words Firefox will always send an SSLv2 hello if SSLv3 is enabled. If you disable SSLv3 (so only TLS is enabled) then it finally stops sending the SSLv2 hello, but at that point something else breaks, a failed handshake can't be retried any more. In other words if you try to connect to foo.com and there's a packet loss or timeout or something similar then any subsequent attempt to connect will instantly fail, until you shut down the browser and restart it. (This was up until about a year ago, so before 3.5, I haven't checked 3.5). Peter. From Chris.Newman@Sun.COM Wed Nov 18 16:29:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF463A6A29 for ; Wed, 18 Nov 2009 16:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 IN-BekpiaVqc for ; Wed, 18 Nov 2009 16:29:41 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 723AF3A6A0A for ; Wed, 18 Nov 2009 16:29:41 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJ0Tb7d007582 for ; Wed, 18 Nov 2009 16:29:37 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00G00YNUMT00@fe-sfbay-09.sun.com> for tls@ietf.org; Wed, 18 Nov 2009 16:29:37 -0800 (PST) Received: from [10.1.110.5] ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB0042CYPAO530@fe-sfbay-09.sun.com>; Wed, 18 Nov 2009 16:29:37 -0800 (PST) Date: Wed, 18 Nov 2009 16:29:34 -0800 From: Chris Newman In-reply-to: <808FD6E27AD4884E94820BC333B2DB774F30FE12B7@NOK-EUMSG-01.mgdnok.nokia.com> Sender: Chris.Newman@Sun.COM To: Pasi.Eronen@nokia.com, mrex@sap.com Message-id: <459D5F289F73FD36855FDCBC@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <808FD6E27AD4884E94820BC333B2DB774F30FE12B7@NOK-EUMSG-01.mgdnok.nokia.com> Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 00:29:42 -0000 --On November 18, 2009 20:02:47 +0100 Pasi.Eronen@nokia.com wrote: > And like the (even simpler) "This is not a renegotiation" magic cipher > suite, it doesn't allow the client to implement a "strict" policy where > it refuses to talk (even in initial handshakes) to non-upgraded servers. > But since many servers that don't support renegotiation (either never > did, or have now disabled it), and thus are not vulnerable, will > probably never implement the protocol changes, I'm not sure such a > "strict" policy for clients would ever be usable (except perhaps in > some small and tightly controlled deployments -- which could quite > well implement the "fully featured" solution with TLS extensions). I want a standardized protocol mechanism that allows a TLS server to assert to my TLS client it is not vulnerable to the renegotiation attack. The vulnerability does not concern me for lower security transactions (like credit card payments) so I'll never want a client to reject all servers lacking the indicator, but it does concern me for higher security transactions (like money transfers) so as a user I need to know. There are institutions I must deal with where I can not trust a statement from their customer service asserting their servers are not vulnerable (the customer service personnel are incented to say what I want to hear to get me off the phone). However, if my client software gets a standardized assertion from their server software, I would consider that an acceptable trust level for higher security transactions. The RI extension provides acceptable signaling from the server to address this customer requirement. - Chris From lists@drh-consultancy.demon.co.uk Wed Nov 18 16:47:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48A63A67F6 for ; Wed, 18 Nov 2009 16:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 fq2MWEg7rxwV for ; Wed, 18 Nov 2009 16:47:08 -0800 (PST) Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by core3.amsl.com (Postfix) with ESMTP id 1274D3A679C for ; Wed, 18 Nov 2009 16:46:43 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50875 helo=[192.168.7.8]) by relay06.mail.eu.clara.net (relay.clara.net [213.253.3.46]:10587) with esmtpa (authdaemon_plain:drh) id 1NAvAV-0008V3-MU (Exim 4.69) for tls@ietf.org (return-path ); Thu, 19 Nov 2009 00:46:40 +0000 Message-ID: <4B049575.4020703@drh-consultancy.demon.co.uk> Date: Thu, 19 Nov 2009 00:46:45 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 00:47:09 -0000 Peter Gutmann wrote: > Martin Rex writes: > >> If you are referring to the SSLv2 backwards-compatibility option, that seems >> to be actually still used in Firefox 3.5 in the automatic reconnect fallback >> should the server choke on TLS extensions. > > The last time I checked it was *always* used, not just as a fallback option. > In other words Firefox will always send an SSLv2 hello if SSLv3 is enabled. If > you disable SSLv3 (so only TLS is enabled) then it finally stops sending the > SSLv2 hello, but at that point something else breaks, a failed handshake can't > be retried any more. In other words if you try to connect to foo.com and > there's a packet loss or timeout or something similar then any subsequent > attempt to connect will instantly fail, until you shut down the browser and > restart it. > > (This was up until about a year ago, so before 3.5, I haven't checked 3.5). > OpenSSL used an SSLv2 compatible client hello until very recently unless extensions were supported/required. The 1.0.0 version uses SSLv3 compatible if all SSLv2 ciphersuites are disabled (they are by default in 1.0.0). Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From noskov@microsoft.com Wed Nov 18 17:24:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3634E3A68EA for ; Wed, 18 Nov 2009 17:24:12 -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 PVYfqkqmOR02 for ; Wed, 18 Nov 2009 17:24:11 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7EEAD3A6867 for ; Wed, 18 Nov 2009 17:24:11 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 Nov 2009 17:24:09 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.21; Wed, 18 Nov 2009 17:24:09 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 18 Nov 2009 17:24:08 -0800 From: Nasko Oskov To: Michael D'Errico , "tls@ietf.org" Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: AQHKaK1f55bCmklGbkWuNva/5lDAuJE8nDxw Date: Thu, 19 Nov 2009 01:23:41 +0000 Deferred-Delivery: Thu, 19 Nov 2009 01:24:00 +0000 Message-ID: References: <4B048E3B.2010506@pobox.com> In-Reply-To: <4B048E3B.2010506@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BrwA CDQO Cdq8 DwdP ErkG HN4I Jwcf KVTO LGxe Ntdo Oxku Qs7k Q6c9 Ro2t SMrJ TslW; 2; bQBpAGsAZQAtAGwAaQBzAHQAQABwAG8AYgBvAHgALgBjAG8AbQA7AHQAbABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {1C374196-E3F1-471D-8584-22DBAA94D270}; bgBvAHMAawBvAHYAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Thu, 19 Nov 2009 01:24:00 GMT; UgBFADoAIABbAFQATABTAF0AIABQAHIAbwBwAG8AcwBhAGwAIABmAG8AcgAgAGgAeQBiAHIAaQBkACAAcwBvAGwAdQB0AGkAbwBuACAAdQBzAGkAbgBnACAAbQBvAHMAdAAgAG8AZgAgAHQAaABlACAAaQBkAGUAYQBzAA== x-cr-puzzleid: {1C374196-E3F1-471D-8584-22DBAA94D270} Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 01:24:12 -0000 Michael D'Errico wrote: > >So you want to have two solutions, one for TLS 1.0+ and another for SSLv3?= =20 >I'm not sure why we need two when any solution that works for SSL will als= o work for TLS. I do not believe the solutions that mess up with the actual protocol are something that should be encouraged in the TLS protocol. Hence I propose at least the running hash behavior is the same, but signaling is different. TL= S has extensions and they are perfectly designed for this purpose. I don't se= e a reason not to use them. Servers that cannot handle properly extensions wi= ll=20 fall back to using SSLv3. >Also the Certificate message is optional, so it would cause trouble for so= me cipher suites. Fair point. >And even more importantly, there is only ServerHello sent when you resume = an old session! Session resumption is already secure since it uses existing crypto state as part of the negotiation. There are no problems in that case. Nasko From yngve@opera.com Wed Nov 18 17:30:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968EE28C15C for ; Wed, 18 Nov 2009 17:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 OtO04tVZWCdZ for ; Wed, 18 Nov 2009 17:30:21 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id D846828C12E for ; Wed, 18 Nov 2009 17:30:20 -0800 (PST) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAJ1T1mD007108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Nov 2009 01:29:02 GMT Date: Thu, 19 Nov 2009 02:30:14 +0100 To: "Nasko Oskov" , "tls@ietf.org" From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.65 (Win32) Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 01:30:22 -0000 Hello Nasko, Let me see if I read this correctly: - For TLS with Extensions, use the RI extension? Is that right? Or another signaling extension? - For SSLv3/TLS without Extensions use the special cipher. Only in this case, or also when the Extension is used, just in case a non-Extension server tolerates Extension (it IS known to happen occasionally), but do understand the cipher? - If the server understand RI, it uses that - If it does not understand the RI, but the cipher, send the special certificate Correct so far? If so, provided that this is always done for all the Client's Hellos, also the first on the connection (I got an impression from your email that this was not required, which could cause problems for first handshakes) I think it should work (though some will say it is too complex, but with this kind of legacy issues you can't fix a problem like this in a simple way). The reason the RI/fallback must be used on the first negotiation is, aside from the MITM attack, that I as a client need to be able to tell up front what I am dealing with, whether to include information in the Security information, adjust security levels, display a warning dialog, or refuse to connect to an unpatched server. I can't wait for a possible renegotiation. Mike was concerned about session resume, but I do not think that is a real issue, since we already know the parameters of the server by this time: - If the server is using RI, the check will be part of the Hellos - If the server is using the fallback, we already know that it does (it is part of the TLS Session information) and modify the Finished calculations accordingly. - If it is using neither, then we also know that, and does not enable the modified Finished calculation mode. The S->C signaling is only needed during a full negotiation, while the C->S signaling is needed each Hello since the server might not want to resume a session. Mike do have a point about the cipher suites that does not use certificates. I am not too concerned about the Anonymous ciphers (they are too vulnerable anyway), but there are IIRC several suites relying on different key exchange methods than PKI (though not supported by Opera). How are those going to be secured? It might be an idea to consider writing this up a bit more formally. On Thu, 19 Nov 2009 00:43:05 +0100, Nasko Oskov wrote: > Currently, many browsers attempt to negotiate TLS with extensions, but > if it fails for any reason, they re-start the negotiation without > extensions (either as a TLS negotiation or an SSLv2/3) negotiation. That > behavior leads to a trivial downgrade attack by a MiTM - all the MiTM > has to do is fail any negotiation with the renegotiation extension > present and wait for the browser to try a negotiation without it. This > leads to situation where the client is unaware if there is MiTM or real > server that doesn't support extensions. If we want browsers to be secure > we have no choice but fixing SSLv3 somehow or disabling it entirely. > > I've been reading all the ideas people have come up with and there are > some good suggestions in all the mails exchanged. After discussing the > various approaches with Paul Leach and passing some ideas around with > Marsh Ray, we came up with a blended approach to solving the overall > problem. I would like to propose a solution that uses some of the ideas > brought up. > We all agree that there are two parts to the solution - signaling and > changing state to allow for detection of the attack (aka > cryptographically binding the two handshakes), so the general spirit is > to use single way of changing state and different signaling for TLS and > SSLv3. > > For SSLv3, we can use the cipher suite idea and define the magic cipher > suite value that SSLv3 client will send out to the server. Based on this > indicator, server knows whether to use regular running hash as it is > today or use the modified running hash. The problem for SSLv3 is the > signal from the server to the client. S->C signaling must be done in a > handshake message preceding the Finish message, so both client and > server can agree on the version of the running hash. The one dynamic > field we know from experience is handled properly by implementations is > the list of certificates. We can use the server Certificate message as > the signal by including specially defined certificate in the list of > certificates sent by the server. If the server sees the magic cipher > suite, the special certificate is included at the end of the certs being > sent. We can define the cert to be the smallest possible server (aka > very little real data in it) and include an unique OID to ensure we > don't col > lide with some real usage of "empty" certificate. > > Here is the matrix for interop: > > Old server New server > ---------------------------------------------------------------------------- > Old Client | as is | server detects old client on > | | ClientHello and can interop > | | based on config > | | > ---------------------------------------------------------------------------- > New Client | detects old server | server detects new client on > | on Certificate message and | initial handshake > | can interop based on config | client detects new server on > | | Certificate > | | both start using the modified > | | running hash > ---------------------------------------------------------------------------- > > There are few ways the running hash can be modified and it seems > inserting the previous Finished message into the running hash is > something everyone agrees should work. Inserting it as the initial input > to the new running hash is a clean approach and allows for easier logic. > The only drawback is that the SSLv3 client will have to keep two hash > states around until the Certificate message is received, but the client > needs to keep the ClientHello around until the ServerHello is received > back, so the complexity should not be much greater. > > For TLS 1.0 and above, we can use this same approach with very little > modification. Since we have clear signaling in the Hello messages using > extensions, both client and server can detect unpatched parties and > based on config either proceed or terminate. The major difference is > that TLS client doesn't have to maintain two different hash states, > since server signals the client and the client can make the decision > whether to hash the previous Finished message into the running hash or > not. As such, the extension as proposed today does not need to transmit > the actual Finished messages, as they will be cached on each end. > > Overall what we achieve is: > * modifying the running hash only for renegotiations, which allows > interop for cases where renego is not needed (a big portion of the > traffic) > * clear signaling in TLS implementations > * backwards compatible solution for SSLv3 > * both sides can interop or not with unpatched parties based on > configuration > * even if both sides are lenient in behavior, they are secure as long as > both of them are patched > * clients falling back from TLS to SSLv3 because of extensions > compatibility will be safe > > Alternatively, we can use the existing draft for TLS and the proposed > solution here for SSLv3. > > Nasko > > P.S. The extension will have to be a "MUST" for all TLS implementations, > otherwise the MiTM can downgrade to TLS without extensions and we are > back at having the problem. This requires, among other things, that > browser fallback logic be slightly changed. There should not be a case > of sending a TLS ClientHello without the extension. If the server reacts > poorly, a downgrade directly to SSLv3 plus the signaling solution should > be attempted. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From nelson@bolyard.me Wed Nov 18 17:57:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C4128C15F for ; Wed, 18 Nov 2009 17:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.492, 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 AuaMO+lyjcSj for ; Wed, 18 Nov 2009 17:57:13 -0800 (PST) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id 3398828C15E for ; Wed, 18 Nov 2009 17:57:13 -0800 (PST) Received: (qmail 31061 invoked from network); 19 Nov 2009 01:57:09 -0000 Received: from unknown (24.5.142.42) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 19 Nov 2009 01:57:09 -0000 Message-ID: <4B04A580.3030801@bolyard.me> Date: Wed, 18 Nov 2009 17:55:12 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 01:57:14 -0000 On 2009-11-18 16:22 PST, Peter Gutmann wrote: > Martin Rex writes: > >> If you are referring to the SSLv2 backwards-compatibility option, that >> seems to be actually still used in Firefox 3.5 in the automatic >> reconnect fallback should the server choke on TLS extensions. > > The last time I checked it was *always* used, not just as a fallback > option. No. SSLv2 compatible hellos are used only in fallback. It's been that way ever since fallback was introduced. > In other words Firefox will always send an SSLv2 hello if SSLv3 is > enabled. No. Once Firefox has found that it cannot connect to a particular server with TLS, but can connect to that server with SSLv3, then for the remainder of the process lifetime, or until the process SSL protocol options are changed, it will remember that that server does not speak TLS, and will not thereafter try to speak TLS to that server. > If you disable SSLv3 (so only TLS is enabled) then it finally stops > sending the SSLv2 hello, Whenever you change the SSL/TLS protocol options, it resets the memory of several things. (Flushes the SSL/TLS session cache, IIRC, among other things.) > but at that point something else breaks, a failed handshake can't be > retried any more. If TLS is the only option it has (because all others are disabled) and TLS fails, then it doesn't try anything else. That's what you'd expect. > In other words if you try to connect to foo.com and there's a packet loss > or timeout or something similar then any subsequent attempt to connect > will instantly fail, until you shut down the browser and restart it. There were some versions of Firefox that had such a bug, yes. > (This was up until about a year ago, so before 3.5, I haven't checked > 3.5). > > Peter. From djhopwood@googlemail.com Wed Nov 18 18:00:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832D23A6809 for ; Wed, 18 Nov 2009 18:00:00 -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 7p1+3AqUAGKb for ; Wed, 18 Nov 2009 17:59:59 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 13B7A3A687D for ; Wed, 18 Nov 2009 17:59:58 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so358121eya.51 for ; Wed, 18 Nov 2009 17:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=FnLgwbwWtaK8mwGapEAKQSC52BiafIxohhA8F684w+I=; b=mqbj3XSJovAAayoqDy8s8Dq+6rfTeYezaTmV48AHTyRnI6mqcxiekp4g/FLQiFpFkd bZ3izs2pSmpCaIC+cCtSm9qwYH+4AgqH1ASKTnryrxtqH96JfRd6zg/+9fLdFiX0myxn 8W9SCKq3PtMvTuQdxKXzJ7DstKB7b8xyYTHBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=V+j+Ayh4Yb61faU1d+iyZ6wy0LU4hfyIjbSx7VMql+4DSLJhhmii/pH4BCm+dDPk0w ro5mYkksJM2y3nA+fHUk6YytC2Xjas2RUs7mCx/BFhosKok+rd47hqhYbX9OVGTc/gJB SWmJNJQTZWX7cxnjuu7PbA1Tqv+zd9gA3wUIo= Received: by 10.213.100.161 with SMTP id y33mr2228597ebn.2.1258595993370; Wed, 18 Nov 2009 17:59:53 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm29282ewy.12.2009.11.18.17.59.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 17:59:52 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B04A694.30505@jacaranda.org> Date: Thu, 19 Nov 2009 01:59:48 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911181436.nAIEagLv024549@fs4113.wdf.sap.corp> In-Reply-To: <200911181436.nAIEagLv024549@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4334A3077741C20E6F722642" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 02:00:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4334A3077741C20E6F722642 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Michael D'Errico wrote: >> You forgot to mention: >> >> 4.3. SSLv3 >> >> SSLv3 does not support extensions and thus it is not possible to >> securely renegotiate with SSLv3. Deployments wishing to renegotia= te >> securely will need to upgrade to at least TLS 1.0. >> >> Is there some secret agenda to kill off SSLv3? What is the point >> of that? SSLv3 accounts for more than one-in-five connections as >> reported to this list. There is an alternate proposal that does not >> have this limitation, and is better in many other respects. Why do >> you keep pushing this one? >=20 > This statement about SSLv3 actually reverts history. >=20 > The fact is, that SSLv3 has THE EXACT SAME provisions for > TLS extensions as TLSv1.0. >=20 > But TLS extensions seems to exclude _itself_ from being used with SSLv3= > -- which looks like a pretty bad idea, given that the extensibility > of TLSv1.0 and SSLv3 is verbatim the same. Neither RFC 3546 nor RFC 4366 mention SSL at all. They do not exclude the extension mechanism from being used with SSL. That usage is not standardized by IETF because SSL is not described in any non-draft IETF document (a decision that I disagree with; I think that SSLv3 should have= been documented in an informational RFC). --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig4334A3077741C20E6F722642 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksEpp0ACgkQWUc8YzyzqAfUqAD/WqilbIGEVfI51kNcYnYy4k/k l/kSqMQVo6XWfF1hMoMA/04HcwhNeR6keGgPkbblEX+2bEMTI8eKhC5PbzCQ6QuL =km34 -----END PGP SIGNATURE----- --------------enig4334A3077741C20E6F722642-- From djhopwood@googlemail.com Wed Nov 18 18:04:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812913A6809 for ; Wed, 18 Nov 2009 18:04:04 -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 UgNpydjdoVin for ; Wed, 18 Nov 2009 18:04:03 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 67D463A67D8 for ; Wed, 18 Nov 2009 18:04:03 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so359023eya.51 for ; Wed, 18 Nov 2009 18:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=sBNjozM9TCpmfvHJSZMyq03OLdl6693E8S03X0huWYo=; b=PhIhT5igyFACDYOsgN4cXpJg7WPBaoGPXGCPwlObDQ27hUlKSHNykRoC+hWaCE5G70 DltaHRq75HliSs3o3b2b6mZnIEguvJnRA8UmvUYISVOwLTo+505lI907VpT0F7/8bPmR sMkFMRaeupAD+ynBvPIPEgp/uV65Ozw3b7cE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=clOWooU8G4eZz8lOVUxnDFSSsAl4Dp8siBpc/WS/MDYv9QrElZllp+S/fEMDdktSA6 usYVswd7ROkuEZOkM5osizxFJs8msP96LqhufDXFitWob/T5AvXeOQCl0o/CeOV+3uaw Cz8vqEyVCfcsMZGPUl4Uoe2Y1JgYIp2gA074o= Received: by 10.213.0.196 with SMTP id 4mr1824913ebc.41.1258596237669; Wed, 18 Nov 2009 18:03:57 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm30211ewy.12.2009.11.18.18.03.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 18:03:57 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B04A792.7040607@jacaranda.org> Date: Thu, 19 Nov 2009 02:04:02 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> In-Reply-To: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF4BCFBECBE4BCE33E423A2E2" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 02:04:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4BCFBECBE4BCE33E423A2E2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > There are going to be components out there that will not get > patched. They might not implement renegotiation (or have it > disabled) and they're therefore not even vulnerable. >=20 > But we can not simply brick them (deny to talk SSL to them > in the future). >=20 > So Browsers will likely have to continue to offer an fallback > to extension-less ClientHello. This is a non-sequitur. Lenient clients don't need to send the extension in the ClientHello of an initial handshake. Strict clients must not be able to talk to unpatched servers, by definition. Unpatched servers *will* eventually be "bricked", as you put it, if they stay unpatched as an increasing proportion of clients adopt a strict policy. There is no possible solution to that other than patching all servers, including those that don't support renegotiation. This is true also for the proposed alternatives to RI. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigF4BCFBECBE4BCE33E423A2E2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksEp5MACgkQWUc8YzyzqAd6dgD/dx0Jz0kXK1no+sNmZGkoNIpp YJRvMhXyDihq+XofLugA/jpwS6pG0doXEFP3AWoO0q9e1+/I9RUBGWrDLMNEAOSF =yGbf -----END PGP SIGNATURE----- --------------enigF4BCFBECBE4BCE33E423A2E2-- From mike-list@pobox.com Wed Nov 18 18:07:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AE43A6826 for ; Wed, 18 Nov 2009 18:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 982TojCfJhkz for ; Wed, 18 Nov 2009 18:07:12 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 3FA3D28C173 for ; Wed, 18 Nov 2009 18:06:58 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 1BAF19FBAA for ; Wed, 18 Nov 2009 21:06:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=2CJ/5DeVg2v9 sbu8SlaLkogJjGw=; b=SJHORVkydZf+A0KevsgctrQAZv9szabZV6XkpfenmHnq ZB9UB+MNeLp7g+dH71pJK7HwR24NkHABMY/KuS4sDA6NK5vv3YEf+79UM/AgeYaA +Hbv6hCygD/lnVMCM/VHV8j9DY5oFvaxrsGy8mfKf237j+Z5527i0G07Pl8JaGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=DpqAke 4U7pUgEL83fWzIkERa5EySdwg9wEFIos2u7gK7ZoLC3MMjnNimgfXYqgwTdptaR/ vRuQn7vvK+sxyPfdn0XnTGt4NORhOhBCEXP79g1FhWxgUXTHjRoPxX4yu4eCJ6JA H2SkWWPjOiEqT8CW0lFbX5KWm5yj7qL5uHIVM= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 188C19FBA9 for ; Wed, 18 Nov 2009 21:06:56 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id B6D459FBA7 for ; Wed, 18 Nov 2009 21:06:55 -0500 (EST) Message-ID: <4B04A88A.7000107@pobox.com> Date: Wed, 18 Nov 2009 18:08:10 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4B048E3B.2010506@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 36732C7E-D4B0-11DE-ADE2-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 02:07:13 -0000 Nasko Oskov wrote: > Session resumption is already secure since it uses existing crypto state as > part of the negotiation. There are no problems in that case. I don't agree -- session resumption is orthogonal to renegotiation, at least in my own code. A MITM could exploit that. This is one part of RI that I agree with. Mike From djhopwood@googlemail.com Wed Nov 18 18:45:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DDE3A6886 for ; Wed, 18 Nov 2009 18:45:00 -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 AQJeis7b1w7Q for ; Wed, 18 Nov 2009 18:44:59 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 12E6E3A685E for ; Wed, 18 Nov 2009 18:44:58 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so368570eya.51 for ; Wed, 18 Nov 2009 18:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=N2D/V8ZqKLPAnjsXVHOD/L3Q3IxNprn4kxL+h6fLCXQ=; b=kOyb2hCinspUAl75OatEnH1lwhxQsu/bbUv1FPJecBJZIicNYeTH83JW2yztgWL0gO kG/okhcT05hNU5G8B3nVzFHivQnnNWsP3lib1hzZC/R4cbIqLeyDGtlwSiI/pWxLB6A4 D/PFZV5eP+Vy0s6Sf72HpGNw4wjCZziVs2hxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=qjXZ4LGRKFfQVs+dJ+l+Hsu/naPuTegGjT+SsBJvAfCJCdYF87xfMd12CPjpa1iFT0 6IjqasX9kh91Ru+grBv9WCWAGT4aSDXUjLk1mzDPV8LuCLFgUXwIsGH0w0pWRhC3ouLA ZX4U2jYGPtvVIx4sfw95KgtZ21N0ea1kAVeI4= Received: by 10.213.23.200 with SMTP id s8mr850802ebb.52.1258598691628; Wed, 18 Nov 2009 18:44:51 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 10sm25502eyd.13.2009.11.18.18.44.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 18:44:51 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B04B11C.4010103@jacaranda.org> Date: Thu, 19 Nov 2009 02:44:44 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B038974.9080001@pobox.com> <20091118154138.210E869FE1E@kilo.networkresonance.com> In-Reply-To: <20091118154138.210E869FE1E@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9707406C1099CE2EC7C4A3F3" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 02:45:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9707406C1099CE2EC7C4A3F3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > At Wed, 18 Nov 2009 15:36:42 +0100 (MET), > Martin Rex wrote: >> Michael D'Errico wrote: >>> You forgot to mention: >>> >>> 4.3. SSLv3 >>> >>> SSLv3 does not support extensions and thus it is not possible to >>> securely renegotiate with SSLv3. Deployments wishing to renegoti= ate >>> securely will need to upgrade to at least TLS 1.0. >>> >>> Is there some secret agenda to kill off SSLv3? What is the point >>> of that? SSLv3 accounts for more than one-in-five connections as >>> reported to this list. There is an alternate proposal that does not >>> have this limitation, and is better in many other respects. Why do >>> you keep pushing this one? >> >> This statement about SSLv3 actually reverts history. >> >> The fact is, that SSLv3 has THE EXACT SAME provisions for >> TLS extensions as TLSv1.0. >> >> But TLS extensions seems to exclude _itself_ from being used with SSLv= 3 >> -- which looks like a pretty bad idea, given that the extensibility >> of TLSv1.0 and SSLv3 is verbatim the same. >=20 > Well, I'm not taking any responsibility for that. I didn't write > the original TLS extensions doc. That said, I suspect the feeling > was that the IETF didn't have any control of SSLv3, and so couldn't > mandate anything about it. Actually, the main argument in the WG at the time was about whether extensions should be delayed until TLS 1.1, or supported for TLS 1.0: (The 'Thread Index' links in each article are busted. The archive by thread is currently at , although that link will become incorrect because older index pages are renamed when the current page becomes full.) I was arguing for extensions to be supported for SSLv3: # Also note that the dns_name attribute is useful for SSL v3.0 as # well, and there's no particular reason to exclude it from being # used in that case (i.e. as a minimal change to servers to allow # them to support virtual hosting without having to implement TLS). but another author of the draft responded with # Re: SSLv3.0, I never intended the dns_name extension to be excluded # from there. However, since this is the TLS working group and since # there is no living specification of SSLv3.0 the point seems moot # and/or out of scope. and there was no dissent to that position. (Note that the "criticality flag" mentioned in that thread was dropped. I think RI would have been the first extension to be "critical" in that sense, when used by strict clients.) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig9707406C1099CE2EC7C4A3F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksEsSUACgkQWUc8YzyzqAdYKQD+NMEut9amTCOCbJGeEgzPG1gL Nz2qMYxultX851nyWQUA/A21MwLBGKApCQQwf1N9qNzR+POgJ1JnkqSesL1ZTvV2 =LjQd -----END PGP SIGNATURE----- --------------enig9707406C1099CE2EC7C4A3F3-- From djhopwood@googlemail.com Wed Nov 18 19:56:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB79D3A682B for ; Wed, 18 Nov 2009 19:56:55 -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 2LbaJ0i6K-Mp for ; Wed, 18 Nov 2009 19:56:54 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 470CB3A6886 for ; Wed, 18 Nov 2009 19:56:54 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so385916eya.51 for ; Wed, 18 Nov 2009 19:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=E3CRIppLXTQD+I49oe7yuX45drjPwVyx6y13CWSNJOE=; b=Yik4NHcetJ/Uw7n4j7TFvHKYMut6Pi8ExlBmaOxgMV01dDGCUH3bieI3MujgGcqugt BwHiSbH38YYr7Q0FO/WzsACwt/5Ahhtfpe0T+QjkuVPqDXSSadbAh/CFkB/C8OsKy0eg 1VFxeEzmX6XiySo9z0IcrHJhIB0tj03+DfBPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=IRL0cDzTjirS8V2gC0+4ow6AA8Za08HMcG23MZUFUUMeSJ2ErOOrak6jEUwpwoX0rG Q13HnB8yn1u2gCWI240RvI33CbKBqoQ1FT2wu2HctHshCodbYTVzLVzBl6yFKyU0NycS n487X/zRJtRV5ASZ9TqrgInmd+wycuUF9jlp4= Received: by 10.213.103.83 with SMTP id j19mr932591ebo.31.1258603008972; Wed, 18 Nov 2009 19:56:48 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 10sm36039eyd.5.2009.11.18.19.56.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 19:56:48 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B04C1F5.7060400@jacaranda.org> Date: Thu, 19 Nov 2009 03:56:37 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <808FD6E27AD4884E94820BC333B2DB774F30FE1154@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 18, 9 03:57:06 pm <200911181647.nAIGlueK002433@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F30FE12B7@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE12B7@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE6575ABDFDF225C3F72664B6" Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 03:56:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE6575ABDFDF225C3F72664B6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pasi.Eronen@nokia.com wrote: > BTW, there's another common renegotiation case where a "low-hanging > fruit" (trivial-to-implement solution known not to cause interop > problems with broken servers) exists: changing from server-only > authentication to mutual authentication (with certificate-based=20 > cipher suites). >=20 > In this case, the client could include a magic "This is a > renegotiation, but with same server certificate" cipher suite in the > renegotiation client hello, and verify that the server certs in the old= > and new sessions are identical (bitwise). This would be just a magic > cipher suite number: no other on-the-wire changes, and no changes to > Finished message calculations. But the server would know this > renegotiation is secure, and could proceed even if it prohibited > "old-style" insecure renegotiation. I don't see the advantage. The client has changed something, therefore it is patched. The server has recognized the change, therefore it is patched. So why are they unable to interoperably perform a "new-style" secure renegotiation? There is no benefit to introducing additional cases= just because a change to the Finished calculations *could* be avoided her= e. (It's actually not clear to me that it can be securely avoided if the server has a wildcard certificate.) > And like the (even simpler) "This is not a renegotiation" magic cipher = > suite, it doesn't allow the client to implement a "strict" policy where= =20 > it refuses to talk (even in initial handshakes) to non-upgraded servers= =2E > But since many servers that don't support renegotiation (either never > did, or have now disabled it), and thus are not vulnerable, will > probably never implement the protocol changes, I'm not sure such a > "strict" policy for clients would ever be usable (except perhaps in > some small and tightly controlled deployments -- which could quite > well implement the "fully featured" solution with TLS extensions). Support for the strict-client policy is non-negotiable :-) as far as I'm concerned. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigE6575ABDFDF225C3F72664B6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksEwf4ACgkQWUc8YzyzqAdAUAD8Ccc4k7fOqCYwNCZIVhywyEVB 5qTos/2I89jjO3hkACQA+wfVSEzeUgYdNeAyhPSD5HKlv1qzGZJcOl2kKHEb6KXH =PZkr -----END PGP SIGNATURE----- --------------enigE6575ABDFDF225C3F72664B6-- From djhopwood@googlemail.com Wed Nov 18 20:10:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E9D3A68B5 for ; Wed, 18 Nov 2009 20:10: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 B6Nu0Li-QXuQ for ; Wed, 18 Nov 2009 20:10:37 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id A4D453A685B for ; Wed, 18 Nov 2009 20:10:36 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so389069eya.51 for ; Wed, 18 Nov 2009 20:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=4jYsQYt4ft28H2e9iDf3ORQOMGsmd7SB4wxOG2gSQHQ=; b=TPkCioTvCU0F9Ae7nkQiDicshqOG3IZFyWDFCvW5uueSnx2cAZ2wGcUUrOMdKjUx8F 9UHJCKOGeYUNe4/qOJodcCshj0VNExAX6lmk0I+F197IiMYFWe1oZ76AxVna2SbhyuRO zQKAbkTJ+sAreB+1loZDBop6rjtwJNKHEnxak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=ZivznbMYjuVzy2N6ahL0KD4XQyR7OuYBMqALOHAzYl9Hs2FlkrI3ngWaeBWgAGPWBA p9Di4M/nutMKVKEzGel4rAB+rCbnZ2QtaGrVWAO5ixvC0xArJsbIvGSZ0smCs8P/ltsM tQBNW8aqgsP/xaw9UfqM8OlKmkLNAPhLhsTHY= Received: by 10.213.100.168 with SMTP id y40mr663686ebn.77.1258603831444; Wed, 18 Nov 2009 20:10:31 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 16sm57751ewy.6.2009.11.18.20.10.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 20:10:30 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B04C52C.4020407@jacaranda.org> Date: Thu, 19 Nov 2009 04:10:20 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4DD8774879E6D0EFAE0E4CE6" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 04:10:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4DD8774879E6D0EFAE0E4CE6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nasko Oskov wrote: > Currently, many browsers attempt to negotiate TLS with extensions, but = if it fails > for any reason, they re-start the negotiation without extensions (eithe= r as a TLS > negotiation or an SSLv2/3) negotiation. That behavior leads to a trivia= l downgrade > attack by a MiTM - all the MiTM has to do is fail any negotiation with = the > renegotiation extension present and wait for the browser to try a negot= iation > without it. This leads to situation where the client is unaware if ther= e is MiTM > or real server that doesn't support extensions. If we want browsers to = be secure > we have no choice but fixing SSLv3 somehow or disabling it entirely. In the RI proposal, if the client doesn't fall back on a renegotiating handshake, then there is no downgrade attack. Falling back to SSLv3 on a renegotiating handshake is not necessary, because the server needs to be patched in order for a renegotiating handshake to succeed. If it is patched, then it is TLS- and extension-tolerant. We *want* renegotiating handshakes with unpatched servers to fail. That i= s not an interoperability bug; it's a security feature. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig4DD8774879E6D0EFAE0E4CE6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksExTQACgkQWUc8YzyzqAeRFAD/d/mEynrLqSY96AT2IeTDJ7sf jip3JepWsBn+qvTrtVkA/0U4fmohjVPJvkxnWrMMb3rzj61evPfbrG2/u7jLBDV5 =o4fP -----END PGP SIGNATURE----- --------------enig4DD8774879E6D0EFAE0E4CE6-- From djhopwood@googlemail.com Wed Nov 18 20:48:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BAF3A68C5 for ; Wed, 18 Nov 2009 20:48:22 -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 61c6KV9Pn37R for ; Wed, 18 Nov 2009 20:48:22 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id B0DE03A6817 for ; Wed, 18 Nov 2009 20:48:21 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so397829eya.51 for ; Wed, 18 Nov 2009 20:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=qg55O1SA+4oJHUASI6zQ/rivG/50laHqsELMtGgSPX8=; b=r9aFtyOB7FBXxBUvJZYZUtxpqtkRrGBXoL5Ybcfb8FQtsV9jq2NCMvNIoa67V0GwyP Q9B655vEfe1xEi7icn1VqX8dlPuFY+9buhTAFilzaCUqe9LEwt3GyHG9wppDdEC46JX8 pHE03IIJHVfXv67j1INosn/Rcz5QAyWNWLUAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=eWl6QZ886KwEXRR0fXWmvEALLHy2uBNxIxrA+B4A+uLse2M48dRZ6Dxejr8FLP8boQ HOTncKg9HHCDi+sydQ6G1XsRM+VkPv71cVxNymM2753X24JwAY7oAsZok0EjR/3pyLR1 VbfjCUCjs3ySmK4+yy3quWYvHHENRbZxk4/bs= Received: by 10.213.24.20 with SMTP id t20mr967184ebb.49.1258606096495; Wed, 18 Nov 2009 20:48:16 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 13sm65851ewy.9.2009.11.18.20.48.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 20:48:16 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B04CE03.4010000@jacaranda.org> Date: Thu, 19 Nov 2009 04:48:03 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp><089F31C221374096B0FE619F@446E7922C82D299DB29D899F><4B02A084.9030903@cs.tcd.ie> <20091117175000.653E669FBC6@kilo.networkresonance.com> <7E1DF37F1F42AB4E877E492C308E6AC40251FFD4@XCH57YKF.rim.net> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC40251FFD4@XCH57YKF.rim.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig887CC8DC6377705AD0C02CA0" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 04:48:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig887CC8DC6377705AD0C02CA0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert Dugal wrote: > I noticed you said this in the jabber log http://www.ietf.org/jabber/lo= gs/tls/2009-11-12.txt=20 >=20 > [06:31:06] It occurred to me the other day that there is a specia= l case where hte server does not need to refuse renegotiation: when the c= lient has sent no data yet. and the session is not resumed, and the server has sent no data. Many application protocols have the client sending a command or "hello" message before the server sends any data, but some don't, and TLS doesn't depend on that. If the server thinks it has already sent some data, then it may not send it again in the renegotiated session, which could confuse the client in that session. > [06:31:20] This would allow step-up/SGC to continue to work 9assu= ming we cared it) >=20 > Our products do support step-up/SGC and some customers may still be usi= ng it, or at least have servers with SGC certificates. > Since there is no vulnerability is this special case, should some note = be added to the draft?=20 SGC is not relevant here; it does not use renegotiation. AFAIK, the only clients that use Step-Up are international versions of Netscape Communicator 4.02 to 4.72 inclusive [*], and possibly some very early versions of Mozilla Suite before its official release. Netscape 4.72 was released in February 2000. Those browsers are completel= y insecure and no-one should still be using them, least of all if they actually need 128-bit encryption. The fact that a server uses a Step-Up certificate does not cause any interoperability problem for other clients. [*] Technical documentation of Step-Up: --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig887CC8DC6377705AD0C02CA0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksEzgoACgkQWUc8YzyzqAeqEAD/dGkVMsoAbXSnbBXBnK5XAXfA S/0AIvUUiIdjHKz3IOUA/3T+R5c+YYwlYMbB/b1u38K+Ku8TM91QkdBLzPMFbi25 =3a5i -----END PGP SIGNATURE----- --------------enig887CC8DC6377705AD0C02CA0-- From djhopwood@googlemail.com Wed Nov 18 20:54:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3103A688F for ; Wed, 18 Nov 2009 20:54:00 -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 6dAMCRcq2z2i for ; Wed, 18 Nov 2009 20:53:59 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 5FF823A6817 for ; Wed, 18 Nov 2009 20:53:59 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so399155eya.51 for ; Wed, 18 Nov 2009 20:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=fMZNXok9zrqaXsoCkAWLS6q754W6MGuD/Eqa7AEPqSw=; b=eO3fujArRRQTo3XF62A50UC3/CiCQ3iIfQ84DwWc6EsJUwuGhgrD3j1/tDxmYTTsO0 I6Uor7rxVL8ZUf66xyjyU47gODuRDLs+xGxkS0TYlp3X5i/zXApt13oOBmTisUD+kTWf 8sCza75uxwRCQJa37+KhANw4OtvWPSnewXN3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=pfSsBwYqD9MGS2bZOFH8gO+HWdhbKq4XJNyrfd7TYR/Pa53p7EbdQbl+L6rmzWrU+y 8vTVenWqtdWT7Zwnia49Vghd8OUCApHR/L8LqgKXywoLM9AIMmUE6NCIdWYfVEwlOOBP qLo5CVRSfr38PzXKYq2miDYDOMqUk1pxRlg2k= Received: by 10.213.8.28 with SMTP id f28mr2907128ebf.39.1258606433452; Wed, 18 Nov 2009 20:53:53 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm66395ewy.12.2009.11.18.20.53.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 20:53:52 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B04CF5B.1050205@jacaranda.org> Date: Thu, 19 Nov 2009 04:53:47 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911182122.nAILMm23018985@fs4113.wdf.sap.corp> In-Reply-To: <200911182122.nAILMm23018985@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC9B2F98E3ED35579C2B7972C" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 04:54:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9B2F98E3ED35579C2B7972C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Robert Dugal wrote: >> Our products do support step-up/SGC and some customers may still be >> using it, or at least have servers with SGC certificates. >> Since there is no vulnerability is this special case, should >> some note be added to the draft?=20 >=20 > You mean like enumerating conceivable usage scenarios that > TLS extension RI is very likely to break? >=20 > Maybe a spec where that section is very small or empty > would be more appreciated by the community. The reason why the fix breaks Step-Up has nothing to do with the use of extensions, and the other proposals that have been made so far would break Step-Up as well. It might be possible to avoid that, but only by adding significant complexity and introducing greater risk of making a mistake that might be exploitable. I'm opposed to adding that complexity and risk. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigC9B2F98E3ED35579C2B7972C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksEz1sACgkQWUc8YzyzqAeimQD/Un0f12ak+/hDxMDdZzzjjJBj /Gh79s1/8aCFMOqdH20A/i4Vl+0C+TCGIknjvwOXZqE/YRnIlxocScRLSKrc7zkt =IQZe -----END PGP SIGNATURE----- --------------enigC9B2F98E3ED35579C2B7972C-- From dispensa@phonefactor.com Wed Nov 18 21:29:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A570F28C0E3 for ; Wed, 18 Nov 2009 21:29:53 -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 WyhdI83URX4E for ; Wed, 18 Nov 2009 21:29:52 -0800 (PST) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id 797E028B797 for ; Wed, 18 Nov 2009 21:29:52 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKSwTXzm/AtsOCi3yZDvTXwheZT8x+Z9SM@postini.com; Wed, 18 Nov 2009 21:29:51 PST Received: from 10.10.9.106 ([10.10.9.106]) by pos-exch1.corp.positivenetworks.net ([204.13.120.8]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Nov 2009 05:27:51 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 18 Nov 2009 23:29:49 -0600 From: Steve Dispensa To: David-Sarah Hopwood , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acpo2U/UpdwvHKAZtUO+MWoBpdMUTA== In-Reply-To: <4B04C52C.4020407@jacaranda.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 05:29:53 -0000 On 11/18/09 10:10 PM, "David-Sarah Hopwood" wrote: > Falling back to SSLv3 on a renegotiating handshake is not necessary, >From the client's perspective, it's an initial negotiation, not a renegotiation. > because the server needs to be patched in order for a renegotiating > handshake to succeed. If it is patched, then it is TLS- and > extension-tolerant. That may be(come) true, but most browsers are currently doing fallback to SSLv3 when things go wrong during (initial) negotiation. That code is in the apps, not the SSL/TLS libraries. For that to become true, you'd have to fix all the servers to handle TLS (nontrivial in old code I understand) *AND* you'd have to get clients to stop falling back to SSLv3. They couldn't stop falling back until the need to fall back (i.e., broken TLS server implementations) disappears, which may take a long time when you consider old code. It will take another long time for browsers to stop falling back. By the way, I'm assuming requiring SSLv3 to support the extension is a non-starter. I realize it's conceptually straightforward to add, but we're talking about adding a major mechanism to the protocol and requiring its use immediately and unconditionally. The client must never send another Client Hello without this extension... If the bad guy can influence the client not to send the extension (e.g., by pretending to be a server that barfs on SSLv3 extensions), and so the browser retries without the extension, he's hosed. I have heard from at least one implementer that requiring SSLv3 clients to send extensions would have high potential for interoperability problems. As long as it's possible for a MitM to cause the client to omit the extension in any way, the extension can't help the client. Now with all that said, I still think the right solution is to use the extension in TLS, since it's architecturally pretty clean; lots of related arguments have been made by others along these lines already. I just think that it's not going to work for SSLv3, and something must be done for SSLv3, or it must be turned off completely in clients. So, I agree with Nasko - two mechanisms - an extension for TLS (and TLS *never* sends another Client Hello without the extension), and an SSLv3 hack of some sort. -Steve From dispensa@phonefactor.com Wed Nov 18 21:35:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9464328B797 for ; Wed, 18 Nov 2009 21:35:13 -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 fw6hADI1eCJo for ; Wed, 18 Nov 2009 21:35:13 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 9C2B428C0D9 for ; Wed, 18 Nov 2009 21:35:12 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKSwTZDgAfOJZVbzu3gTGIGAy2NQU3mbjq@postini.com; Wed, 18 Nov 2009 21:35:11 PST Received: from 10.10.9.106 ([10.10.9.106]) by pos-exch1.corp.positivenetworks.net ([204.13.120.8]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Nov 2009 05:33:12 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 18 Nov 2009 23:35:07 -0600 From: Steve Dispensa To: "Yngve N. Pettersen (Developer Opera Software ASA)" , Nasko Oskov , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acpo2g1fCjUAiYTpnU+KaMCDtMrIuQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 05:35:13 -0000 On 11/18/09 7:30 PM, "Yngve N. Pettersen (Developer Opera Software ASA)" wrote: > - For TLS with Extensions, use the RI extension? Is that right? Or > another signaling extension? I think he means it more broadly: for TLS, use an extension. All TLS must support the extension. -Steve From stefan@aaa-sec.com Wed Nov 18 23:49:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3ECD3A6A3B for ; Wed, 18 Nov 2009 23:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_20=-0.74, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAEKpfkDyWJU for ; Wed, 18 Nov 2009 23:49:07 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 33DDD3A67B6 for ; Wed, 18 Nov 2009 23:49:06 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DFAA228B186 for ; Thu, 19 Nov 2009 08:49:04 +0100 (CET) Received: (qmail 24701 invoked from network); 19 Nov 2009 07:49:02 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Nov 2009 07:49:02 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 19 Nov 2009 08:49:01 +0100 From: Stefan Santesson To: Steve Dispensa , David-Sarah Hopwood , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acpo2U/UpdwvHKAZtUO+MWoBpdMUTAAE3IsT In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 07:49:08 -0000 I think the important point of this thread is that there are strong arguments for providing a solution for SSLv3, not using extensions. What I don't understand is the rationale for providing two solutions, when one solution could work for all cases. Finally, I don't like the certificate signaling solutions for reasons mentioned. It may also disturb the efficiency of information caching according to the cached info draft (even though that might be a minor concern). /Stefan On 09-11-19 6:29 AM, "Steve Dispensa" wrote: > > Now with all that said, I still think the right solution is to use the > extension in TLS, since it's architecturally pretty clean; lots of related > arguments have been made by others along these lines already. I just think > that it's not going to work for SSLv3, and something must be done for SSLv3, > or it must be turned off completely in clients. From marsh@extendedsubset.com Wed Nov 18 23:52:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0A43A67B6 for ; Wed, 18 Nov 2009 23:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 SiOIFhmI22sR for ; Wed, 18 Nov 2009 23:52:14 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 801BE3A686E for ; Wed, 18 Nov 2009 23:52:14 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NB1oK-000Dc3-3O for tls@ietf.org; Thu, 19 Nov 2009 07:52:12 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1DCCE667C for ; Thu, 19 Nov 2009 07:52:11 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/JaF3NL4orzaHosGsoi6Ry7u/OFfPxpfM= Message-ID: <4B04F92A.8050903@extendedsubset.com> Date: Thu, 19 Nov 2009 01:52:10 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 07:52:15 -0000 Stefan Santesson wrote: > > What I don't understand is the rationale for providing two solutions, when > one solution could work for all cases. TLS can support a nice, clean, efficient solution going forward. SSLv3 needs an ugly dirty hack, no way around it. - Marsh From stefan@aaa-sec.com Thu Nov 19 00:11:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FD63A690D for ; Thu, 19 Nov 2009 00:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRhT0maOlezy for ; Thu, 19 Nov 2009 00:10:55 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 7B24E3A67EF for ; Thu, 19 Nov 2009 00:10:54 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D89F6293F5E for ; Thu, 19 Nov 2009 09:10:09 +0100 (CET) Received: (qmail 70030 invoked from network); 19 Nov 2009 08:10:07 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Nov 2009 08:10:07 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 19 Nov 2009 09:10:03 +0100 From: Stefan Santesson To: Marsh Ray , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acpo77I4519e291ZjkaMOA59EksXQw== In-Reply-To: <4B04F92A.8050903@extendedsubset.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 08:11:02 -0000 On 09-11-19 8:52 AM, "Marsh Ray" wrote: > Stefan Santesson wrote: >> >> What I don't understand is the rationale for providing two solutions, when >> one solution could work for all cases. > > TLS can support a nice, clean, efficient solution going forward. > > SSLv3 needs an ugly dirty hack, no way around it. > I disagree. I think we agree that an upgraded finished calculation is not a dirty hack. This is what future versions of TLS will use by default. Remains then the signaling C->S and S->C client. The RI proposal also includes the use of a magic cipher suite, so that dirty hack is in both proposals. Which leaves us with S->C signaling. Here I'm not sure we have exhausted all options. One way to approach this (and bring the proposals together) would be to use the same updated finished calculations in both approaches and just use the RI extension for signaling. In such case we could simply reduce this discussion to debate different ways to accomplish signaling for various versions of the protocol. /Stefan > - Marsh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nelson@bolyard.me Thu Nov 19 00:41:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6943A6881 for ; Thu, 19 Nov 2009 00:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, 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 QGY--0oY8d55 for ; Thu, 19 Nov 2009 00:41:55 -0800 (PST) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 796A43A6858 for ; Thu, 19 Nov 2009 00:41:55 -0800 (PST) Received: (qmail 32382 invoked from network); 19 Nov 2009 08:41:52 -0000 Received: from unknown (24.5.142.42) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 19 Nov 2009 08:41:52 -0000 Message-ID: <4B05045B.9060402@bolyard.me> Date: Thu, 19 Nov 2009 00:39:55 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Steve Dispensa References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 08:41:56 -0000 On 2009-11-18 21:29 PST, Steve Dispensa wrote: > On 11/18/09 10:10 PM, "David-Sarah Hopwood" > wrote: >> [...] the server needs to be patched in order for a renegotiating >> handshake to succeed. If it is patched, then it is TLS- and extension- >> tolerant. > > That may be(come) true, but most browsers are currently doing fallback to > SSLv3 when things go wrong during (initial) negotiation. That code is in > the apps, not the SSL/TLS libraries. > > For that to become true, you'd have to fix all the servers to handle TLS > (nontrivial in old code I understand) *AND* you'd have to get clients to > stop falling back to SSLv3. They couldn't stop falling back until the > need to fall back (i.e., broken TLS server implementations) disappears, > which may take a long time when you consider old code. It will take > another long time for browsers to stop falling back. Not necessarily. When the browser community perceives that all the old "TLS-intolerant" (and extension intolerant) servers are all vulnerable, and when the perception of this vulnerability rises to the point where browser makers believe their users demand a way to ensure that they no longer connect to vulnerable servers (and hence become vulnerable), then the support for fall-back could end rather quickly, I believe. If the major browser makers all agree, then it might just get cut off cold at some point. Otherwise, it might appear as a user configurable option, and if/when sufficient numbers of users flip that switch, and admins of vulnerable servers see usage drop off, servers will finally get upgraded. > So, I agree with Nasko - two mechanisms - an extension for TLS (and TLS > *never* sends another Client Hello without the extension), and an SSLv3 > hack of some sort. +1 From stefan@aaa-sec.com Thu Nov 19 00:45:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC0B3A6899 for ; Thu, 19 Nov 2009 00:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-1.685, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvyGeCGjHa6K for ; Thu, 19 Nov 2009 00:45:45 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id A6C623A6858 for ; Thu, 19 Nov 2009 00:45:45 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 11C64290301 for ; Thu, 19 Nov 2009 09:45:45 +0100 (CET) Received: (qmail 11762 invoked from network); 19 Nov 2009 08:45:42 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Nov 2009 08:45:42 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 19 Nov 2009 09:45:41 +0100 From: Stefan Santesson To: "tls@ietf.org" Message-ID: Thread-Topic: Need for S->C signaling Thread-Index: Acpo9KyRPgf2+uHuMUmsQXxOU+h1aA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341468742_8410572" Subject: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 08:45:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3341468742_8410572 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Just a question to make sure we have accurately exhausted this aspect. Is it really necessary for the Server to signal that is is patched other than using a modified finished calculation if it is patched/upgraded. One scenario could be: 1) Client use the magic cipher suite to signal that it is patched/upgraded. 2) Client sends a normal finished message. 3a) Un-patched server replies with normal finished message. 3b) Patched server replies with upgraded finished message. This way the client could determine whether the server is patched or not an= d act accordingly and get the security context of renegotiate from the patche= d server. There are probably reasons why this is not a good idea. I=B9m just not really sure what they are. /Stefan --B_3341468742_8410572 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Need for S->C signaling Just a question to make sure we have accurately exhausted this aspect.

Is it really necessary for the Server to signal that is is patched other th= an using a modified finished calculation if it is patched/upgraded.

One scenario could be:

1) Client use the magic cipher suite to signal that it is patched/upgraded.=
2) Client sends a normal finished message.
3a) Un-patched server replies with normal finished message.
3b) Patched server replies with upgraded finished message.

This way the client could determine whether the server is patched or not an= d act accordingly and get the security context of renegotiate from the patch= ed server.

There are probably reasons why this is not a good idea. I’m just not = really sure what they are.

/Stefan --B_3341468742_8410572-- From ynir@checkpoint.com Thu Nov 19 00:47:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877313A680B for ; Thu, 19 Nov 2009 00:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 2xRD7qQO4ysl for ; Thu, 19 Nov 2009 00:47:33 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 840A13A67F9 for ; Thu, 19 Nov 2009 00:47:33 -0800 (PST) X-CheckPoint: {4B0502AA-E-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BF0C929C002; Thu, 19 Nov 2009 10:47:30 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 41A4129C009; Thu, 19 Nov 2009 10:47:30 +0200 (IST) X-CheckPoint: {4B0502AA-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAJ8lTGo013170; Thu, 19 Nov 2009 10:47:29 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 19 Nov 2009 10:47:35 +0200 From: Yoav Nir To: Stefan Santesson Date: Thu, 19 Nov 2009 10:47:29 +0200 Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acpo9PB/RiF17Z0FSc6+eU2RxmlhSA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 08:47:34 -0000 On Nov 19, 2009, at 10:10 AM, Stefan Santesson wrote: >=20 > I disagree. >=20 > I think we agree that an upgraded finished calculation is not a dirty hac= k. > This is what future versions of TLS will use by default. >=20 > Remains then the signaling C->S and S->C client. >=20 > The RI proposal also includes the use of a magic cipher suite, so that di= rty > hack is in both proposals. >=20 > Which leaves us with S->C signaling. Here I'm not sure we have exhausted = all > options. I've got one more. =20 Change the Finished message calculation to include the old verify_data. Th= at's in all proposals. I would add to that to also change the Finished message calculation in the = initial negotiation, and use a single zero byte for the old verify_data, bu= t do this for the client only. That way, the client can attempt to calculate the Finished message in both = the old and new way, and recognize if the server is patched or not. I realize this is less than optimal, because in the normal handshake, the c= lient's ChangeCipherSpec and Finished message precede the server's, so we c= an't alter the client's Finished message in the same way without breaking c= onnectivity with un-patched servers.= From ynir@checkpoint.com Thu Nov 19 04:12:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CA23A6B25 for ; Thu, 19 Nov 2009 04:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kObf1daLGU5e for ; Thu, 19 Nov 2009 04:12:52 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id BEC113A68AF for ; Thu, 19 Nov 2009 04:12:50 -0800 (PST) X-CheckPoint: {4B0532C3-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C73F029C009; Thu, 19 Nov 2009 14:12:41 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A802329C002; Thu, 19 Nov 2009 14:12:41 +0200 (IST) X-CheckPoint: {4B0532BF-3-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAJCCeGo010603; Thu, 19 Nov 2009 14:12:41 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 19 Nov 2009 14:12:47 +0200 From: Yoav Nir To: Stefan Santesson Date: Thu, 19 Nov 2009 14:12:41 +0200 Thread-Topic: [TLS] Need for S->C signaling Thread-Index: AcppEZs6cLfh3005REaLQUv8m4pK5Q== Message-ID: <61B8C989-B276-4DEF-A353-284BB981D2F9@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_61B8C989B2764DEFA353284BB981D2F9checkpointcom_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:13:00 -0000 --_000_61B8C989B2764DEFA353284BB981D2F9checkpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Nov 19, 2009, at 10:45 AM, Stefan Santesson wrote: Just a question to make sure we have accurately exhausted this aspect. Is it really necessary for the Server to signal that is is patched other th= an using a modified finished calculation if it is patched/upgraded. One scenario could be: 1) Client use the magic cipher suite to signal that it is patched/upgraded. 2) Client sends a normal finished message. 3a) Un-patched server replies with normal finished message. 3b) Patched server replies with upgraded finished message. This way the client could determine whether the server is patched or not an= d act accordingly and get the security context of renegotiate from the patc= hed server. There are probably reasons why this is not a good idea. I=92m just not real= ly sure what they are. That only works if you change even the initial Finished message (which I'm = all for, btw) Not a "good" reason, but vulnerability scanners want to fingerprint which s= ervers are patched and which are not patched. Signaling in ServerHello allows them to do it immediately, while having to = determine this by the Finished message is harder. A slightly better reason is that the logic the client has to implement is s= lightly more complex, and you lose one bit of security (two right answers).= This is not too bad IMO Anyway, I like this proposal just fine. --_000_61B8C989B2764DEFA353284BB981D2F9checkpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
On Nov 19, 2= 009, at 10:45 AM, Stefan Santesson wrote:

Just a question to make sure we have accurately exhausted this aspect= .

Is it really necessary for the Server to signal that is is patched other th= an using a modified finished calculation if it is patched/upgraded.

One scenario could be:

1) Client use the magic cipher suite to signal that it is patched/upgraded.=
2) Client sends a normal finished message.
3a) Un-patched server replies with normal finished message.
3b) Patched server replies with upgraded finished message.

This way the client could determine whether the server is patched or not an= d act accordingly and get the security context of renegotiate from the patc= hed server.

There are probably reasons why this is not a good idea. I=92m just not real= ly sure what they are.

<= /div>That only= works if you change even the initial Finished message (which I'm all for, = btw)

Not a "good" reason, but vulnerability scanners want to fingerprint w= hich servers are patched and which are not patched.

Signaling in Serv= erHello allows them to do it immediately, while having to determine this by= the Finished message is harder.

=
A slightly better reason is that the= logic the client has to implement is slightly more complex, and you lose o= ne bit of security (two right answers). This is not too bad IMO

Anywa= y, I like this proposal just fine.

= --_000_61B8C989B2764DEFA353284BB981D2F9checkpointcom_-- From lists@drh-consultancy.demon.co.uk Thu Nov 19 04:41:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883D93A691B for ; Thu, 19 Nov 2009 04:41:22 -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 FpKrOvV2DiCX for ; Thu, 19 Nov 2009 04:41:22 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by core3.amsl.com (Postfix) with ESMTP id 51F4228C0E3 for ; Thu, 19 Nov 2009 04:41:22 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49182 helo=[192.168.7.8]) by relay01.mail.eu.clara.net (relay.clara.net [213.253.3.41]:10587) with esmtpa (authdaemon_plain:drh) id 1NB6K6-0002DX-6I (Exim 4.69) for tls@ietf.org (return-path ); Thu, 19 Nov 2009 12:41:19 +0000 Message-ID: <4B053CF5.7000105@drh-consultancy.demon.co.uk> Date: Thu, 19 Nov 2009 12:41:25 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4B04F92A.8050903@extendedsubset.com> In-Reply-To: <4B04F92A.8050903@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:41:22 -0000 Marsh Ray wrote: > Stefan Santesson wrote: >> What I don't understand is the rationale for providing two solutions, when >> one solution could work for all cases. > > TLS can support a nice, clean, efficient solution going forward. > > SSLv3 needs an ugly dirty hack, no way around it. > That's would work if you are only using TLS or know a server supports TLS in advance. What browsers and many libraries (including OpenSSL) do in the first place is to send an initial "version discovery" SSLv3 compatible client hello (or even SSLv2) with the version number set to the maximum number of SSL/TLS supported. The reply then indicates the version of SSL/TLS supported. Until that point you don't know what the server supports. So the connection can end up talking TLS v1.2 even though it initially sent and SSLv3 compatible client hello. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Thu Nov 19 06:23:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFAF3A69CB for ; Thu, 19 Nov 2009 06:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_CODEINE=0.833] 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+k9UDWYaMwu for ; Thu, 19 Nov 2009 06:23:45 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 7E63C3A68CC for ; Thu, 19 Nov 2009 06:23:45 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAJENdF0022915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 15:23:39 +0100 (MET) From: Martin Rex Message-Id: <200911191423.nAJENbmG019990@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 19 Nov 2009 15:23:37 +0100 (MET) In-Reply-To: <4B04F92A.8050903@extendedsubset.com> from "Marsh Ray" at Nov 19, 9 01:52:10 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:23:46 -0000 Marsh Ray wrote: > > Stefan Santesson wrote: > > > > What I don't understand is the rationale for providing two solutions, when > > one solution could work for all cases. > > TLS can support a nice, clean, efficient solution going forward. > > SSLv3 needs an ugly dirty hack, no way around it. I'm sorry but you are mis-representing the facts in an unfair fashion. Both approaches, TLS extension RI and my extension-free solution change the existing protocol in the _exact_ same fashion from an abstract point of view: - both approaches add the verify_data of Client.Finished and Server.Finished into the handshake message hash directly after the ServerHello handshake message for renegotiation handshakes - both approaches use the ClientHello and the ServerHello for signaling/negotiation The changes only materialize in different bits-on-the-wire and use a slightly different sequence of API calls to achieve this. The extension-less approach is going to be applicable to all existing usage scenarios (even the SSLv2-compatible ClientHello I think) and does not change the bits-on-the-wire of the renegotiation handshake at all adds a ciphersuite ID to ClientHello and re-purposes a single bit in the ServerHello -- it is difficult to conceive to make this any more conservative. The code changes required for the extension-less approach is extremely small, non-ambiguous and almost trivial to test for interoperability. obvious problems of TLS extension RI: - adds significantly more bits-on-the-wire to initial and renegotiation handshakes - modifies the initial and renegotiation handshakes in different ways - is NON-interoperable with a significant amount of the installed base of SSLv3 _AND_ TLSv1.0 servers - can NOT be used in apps-level extension-less ClientHello fallbacks as implemented in most current Browsers - is vulnerable to downgrade attacks because of its incompatibilty with apps-level extension-less ClientHello fallback - can NOT be used in conservative clients that do not contain an apps-level extension-less ClientHello fallback - requires more code changes to implement than extension-less approach in newer codelines - requires _significantly_ more code changes to implement than extension-less approach in older codelines without TLS extensions - clients and servers that do not implement renegotiation at all need the full amount of code changes - significantly more complex test-scenarios, development of interop test tools required for reliable interop-testing, even for implementations that do NOT contain renegotiation. -Martin From noskov@microsoft.com Thu Nov 19 07:35:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1E33A6958 for ; Thu, 19 Nov 2009 07:35:12 -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 opQNsk-z6G5N for ; Thu, 19 Nov 2009 07:35:12 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1E4463A6860 for ; Thu, 19 Nov 2009 07:35:12 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 Nov 2009 07:35:31 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.21; Thu, 19 Nov 2009 07:35:09 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 19 Nov 2009 07:35:08 -0800 From: Nasko Oskov To: "tls@ietf.org" Thread-Topic: Need for S->C signaling Thread-Index: Acpo9KyRPgf2+uHuMUmsQXxOU+h1aAAOJkXw Date: Thu, 19 Nov 2009 15:32:03 +0000 Deferred-Delivery: Thu, 19 Nov 2009 15:33:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 15:35:12 -0000 Stefan Santesson wrote: >Just a question to make sure we have accurately exhausted this aspect. > >Is it really necessary for the Server to signal that is is patched other t= han=20 >using a modified finished calculation if it is patched/upgraded. Yes. If you use the finished message, the attack is still possible. >One scenario could be: > >1) Client use the magic cipher suite to signal that it is patched/upgraded= . >2) Client sends a normal finished message. >3a) Un-patched server replies with normal finished message. >3b) Patched server replies with upgraded finished message. > >This way the client could determine whether the server is patched or not >and act accordingly and get the security context of renegotiate from the >patched server. Once the server replies with the Finished message, it would move to connected state and the HTTP stack is clear to execute the MiTM request. As part of developing proof of concept for our own testing, I've observed that connecting to IIS server will send the server CCS, Finished, App data. Even if the client were to drop the connection, the request has been executed and attack is carried out. >There are probably reasons why this is not a good idea. I'm just not reall= y >sure what they are. From noskov@microsoft.com Thu Nov 19 07:47:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C463A6878 for ; Thu, 19 Nov 2009 07:47:46 -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 4Df5iXY-QQyh for ; Thu, 19 Nov 2009 07:47:45 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 60A913A6358 for ; Thu, 19 Nov 2009 07:47:45 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 Nov 2009 07:48:04 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.21; Thu, 19 Nov 2009 07:47:43 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 19 Nov 2009 07:47:42 -0800 From: Nasko Oskov To: "tls@ietf.org" Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: AQHKaM5JSzUmjMY3F0i7YWorO/+ELpE9Zx+AgAAm5ICAAADiAIAABP+A///5EoA= Date: Thu, 19 Nov 2009 15:45:34 +0000 Deferred-Delivery: Thu, 19 Nov 2009 15:46:00 +0000 Message-ID: References: <4B04F92A.8050903@extendedsubset.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Agr/ Bxcq Cz27 DPLp Dqqa D3Qb EFJB EuHD Fn9s F4YE F/g4 GyI9 HdNG Hd/J IV3V JWD3; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {023F061E-7B41-4963-92F8-A806B7F19E8A}; bgBvAHMAawBvAHYAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Thu, 19 Nov 2009 15:46:00 GMT; UgBFADoAIABbAFQATABTAF0AIABQAHIAbwBwAG8AcwBhAGwAIABmAG8AcgAgAGgAeQBiAHIAaQBkACAAcwBvAGwAdQB0AGkAbwBuACAAdQBzAGkAbgBnACAAbQBvAHMAdAAgAG8AZgAgAHQAaABlACAAaQBkAGUAYQBzAA== x-cr-puzzleid: {023F061E-7B41-4963-92F8-A806B7F19E8A} Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 15:47:46 -0000 Stefan Santesson wrote: >On 09-11-19 8:52 AM, "Marsh Ray" wrote: >> Stefan Santesson wrote: >>>=20 >>> What I don't understand is the rationale for providing two solutions,=20 >>> when one solution could work for all cases. >>=20 >> TLS can support a nice, clean, efficient solution going forward. >>=20 >> SSLv3 needs an ugly dirty hack, no way around it. >>=20 > >I disagree. > >I think we agree that an upgraded finished calculation is not a dirty hack= . >This is what future versions of TLS will use by default. Agreed. >Remains then the signaling C->S and S->C client. > >The RI proposal also includes the use of a magic cipher suite, so that dir= ty hack is in both proposals. > >Which leaves us with S->C signaling. Here I'm not sure we have exhausted a= ll options. Yes, we might be missing something else. The reason I picked the Certificat= e message is that it is dynamic size by default, so we don't have to alter existing data, just append. >One way to approach this (and bring the proposals together) would be to us= e >the same updated finished calculations in both approaches and just use the >RI extension for signaling. In such case we could simply reduce this >discussion to debate different ways to accomplish signaling for various >versions of the protocol. I realize I could've been more precise in my initial proposal. This is exactly the essence of it. Finished calculations are the same across the board, just signaling is different. TLS to use extensions, SSLv3 to use whatever hack we agree on. Nasko From stephen.farrell@cs.tcd.ie Thu Nov 19 08:30:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB89E3A6A9A for ; Thu, 19 Nov 2009 08:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j-kXKoyD3Tx for ; Thu, 19 Nov 2009 08:30:59 -0800 (PST) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.15]) by core3.amsl.com (Postfix) with ESMTP id DDC2E3A6AAB for ; Thu, 19 Nov 2009 08:30:58 -0800 (PST) Received: from mail37-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 8.1.340.0; Thu, 19 Nov 2009 16:30:56 +0000 Received: from mail37-va3 (localhost.localdomain [127.0.0.1]) by mail37-va3-R.bigfish.com (Postfix) with ESMTP id 3C4863A8734 for ; Thu, 19 Nov 2009 16:30:56 +0000 (UTC) X-SpamScore: -16 X-BigFish: VPS-16(zz1432R98dNzz1202hzzz2dh6bh87h62h) X-Spam-TCS-SCL: 1:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail37-va3 (localhost.localdomain [127.0.0.1]) by mail37-va3 (MessageSwitch) id 1258648254857333_22697; Thu, 19 Nov 2009 16:30:54 +0000 (UTC) Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.241]) by mail37-va3.bigfish.com (Postfix) with ESMTP id C02871828056; Thu, 19 Nov 2009 16:30:54 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server id 14.0.482.32; Thu, 19 Nov 2009 16:30:51 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id C6B2D68002; Thu, 19 Nov 2009 16:30:50 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A07CDCC30B1; Thu, 19 Nov 2009 16:30:50 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id AD47D68002; Thu, 19 Nov 2009 16:30:50 +0000 (GMT) Message-ID: <4B0572BD.5060507@cs.tcd.ie> Date: Thu, 19 Nov 2009 16:30:53 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Nasko Oskov References: <4B04F92A.8050903@extendedsubset.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A17CDCC30B1 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.22) X-Reverse-DNS: imx2.tcd.ie Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:30:59 -0000 Nasko Oskov wrote: >> Which leaves us with S->C signaling. Here I'm not sure we have exhausted all options. > > Yes, we might be missing something else. The reason I picked the Certificate > message is that it is dynamic size by default, so we don't have to alter > existing data, just append. Sorry, I'm not clear on what's being proposed here. Is it: a) embed a new flag of some sort in a CA-issued X.509 cert b) add an additional server-generated self-signed cert containing a new flag of some sort c) something else? I think (a) would be a bad idea. Not sure about (b) either, but at least it wouldn't bring a whole new bunch of parties to the table (CA product vendors and service providers) when something quick is what's needed. Stephen. From mike-list@pobox.com Thu Nov 19 09:07:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA3A3A6B59 for ; Thu, 19 Nov 2009 09:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJ6g6ukT-CvH for ; Thu, 19 Nov 2009 09:07:19 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id E1B913A6A26 for ; Thu, 19 Nov 2009 09:07:18 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 6FF719FF95 for ; Thu, 19 Nov 2009 12:07:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=iDd6lCLaNj/4 RPK9TCDpJf8dPTI=; b=Fbt9s5psDUKSXBqo8EM86F+vZE3aJB6oHLufHHt7mpHW NvzgJBP/8JKFemTj/JvvWV0ZsxC5eE6XgZwL8GhkiYFDn237MjVJM3Ec8yIjMd9b lL64mZOTZ1jaUBCmOBYTY0MJlhUArBsokMaeAZXRj4xOIp1lnRvMUz2oSCV/ajw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ZvjK0L l7p11ZHlTNWWhIuFKyXmZNjhPZ/9vY9aRxzPQoG+QVXUE7b0l3t1pw0dehxhbict B6W3nDajY3feAifhqCUrWAyUEa6Yc5CMamE5Q5Iy0yVbq7nU0aMwzFi92mdB+w1l TVgllKqmgks7/AK4mLMgwMjl4iaUnbotF5rEs= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 6D12D9FF94 for ; Thu, 19 Nov 2009 12:07:16 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id D55BC9FF93 for ; Thu, 19 Nov 2009 12:07:15 -0500 (EST) Message-ID: <4B057B8A.4000809@pobox.com> Date: Thu, 19 Nov 2009 09:08:26 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B04F92A.8050903@extendedsubset.com> In-Reply-To: <4B04F92A.8050903@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: FD164938-D52D-11DE-838D-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] Justification for "Ugly Dirty Hack" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:07:19 -0000 Marsh Ray wrote: > Stefan Santesson wrote: >> What I don't understand is the rationale for providing two solutions, when >> one solution could work for all cases. > > TLS can support a nice, clean, efficient solution going forward. > > SSLv3 needs an ugly dirty hack, no way around it. This appears to be the opposition to a solution that does not use extensions. That it is an "ugly dirty hack." Here is how I think about it: We are in fact creating new versions of the protocol. But not in the sense that the existing version numbering scheme requires, i.e. a strict linear progression from one version to the next. We currently have 4 versions: SSLv3, TLS1.0, TLS1.1, TLS1.2. We are in a sense creating 4 new parallel versions: SSLv3p, TLS1.0p, TLS1.1p, and TLS1.2p (p meaning patched). These four new versions sort of interleave into the list we already have, thus we can't do what would normally be done to select which version the client wants. The extension-less approach Martin is writing up has the client include a "magic" cipher suite in its hello message to let the server know it is patched and can therefore negotiate one of the new "p" versions. If the server is unpatched, it will ignore the magic cipher suite and continue as normal. But if it is patched, then there needs to be an unambiguous way to signal that it has selected a "p" version. Using the server version in the ServerHello is a natural place to put that. My suggestion is to set the upper bit of the minor version field. This provides a clear and unmistakable signal to the client, and is completely contained within the 0x03 major version number space. Is it a "hack", yeah, but it's entirely reasonable. Repurposing the Certificate message seems like WAYYYY more of a hack than this! This is also entirely forward-compatible. The next published version of TLS would be "TLS 4.0" {0x04,0x00}, which is greater than any of the existing versions and also the "p" versions if the minor version signals them. Mike From mrex@sap.com Thu Nov 19 09:49:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075E23A6964 for ; Thu, 19 Nov 2009 09:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.055 X-Spam-Level: X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=0.194, 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 QOULTycX8lsV for ; Thu, 19 Nov 2009 09:49:07 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id EDC283A6927 for ; Thu, 19 Nov 2009 09:49:06 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAJHn3gU009954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 18:49:03 +0100 (MET) From: Martin Rex Message-Id: <200911191749.nAJHn2IT001762@fs4113.wdf.sap.corp> To: noskov@microsoft.com (Nasko Oskov) Date: Thu, 19 Nov 2009 18:49:02 +0100 (MET) In-Reply-To: from "Nasko Oskov" at Nov 19, 9 03:45:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:49:08 -0000 Nasko Oskov wrote: > > > >I think we agree that an upgraded finished calculation is not a dirty hack. > >This is what future versions of TLS will use by default. > > Agreed. So far it is actually an upgraded handshake message hash calculation for the renegotiation handshake. TLS extension RI uses two extra layers of wrapping ExtendenServerHello( TLS-extension-RI( previous.Client.Finished.verify_data | previousServer.Finished.verify_data ) ) where as I'm prefering a more environmentalist approach, adding the verify_data of the previous Client.Finished and Server.Finished directly to the handshake message hash without any gift wrapping. > > Yes, we might be missing something else. The reason I picked the Certificate > message is that it is dynamic size by default, so we don't have to alter > existing data, just append. To me that feels very wrong to use the Certificate message. I'm convinced that it should go into the ServerHello. I'm not questioning that ServerHello is the correct place for all of the cryptographic parameters _and_ the TLS extensions. The Certificate message is not part of TLS handshakes with server-anonymous ciphersuites and it is equally missing on TLS session resume handshakes and I _really_ want to have the server signal on each and every TLS handshake! I would not even try to think about justifications why it might be OK to omit it on some of the handshakes (My intuition says, this is going to come back at us one way or the other if we did this). > > I realize I could've been more precise in my initial proposal. This is > exactly the essence of it. Finished calculations are the same across the > board, just signaling is different. TLS to use extensions, SSLv3 to use > whatever hack we agree on. This would add the complexity of the solution and double the interop testing scenarios. Why use two signaling mechanism where one is perfectly sufficient? -Martin From lists@drh-consultancy.demon.co.uk Thu Nov 19 10:05:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4903A66B4 for ; Thu, 19 Nov 2009 10:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 nudY+1CIXRob for ; Thu, 19 Nov 2009 10:05:45 -0800 (PST) Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by core3.amsl.com (Postfix) with ESMTP id B23BA3A6953 for ; Thu, 19 Nov 2009 10:05:45 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50225 helo=[192.168.7.8]) by relay03.mail.eu.clara.net (relay.clara.net [213.253.3.43]:10587) with esmtpa (authdaemon_plain:drh) id 1NBBNw-0006Bs-Ch (Exim 4.69) for tls@ietf.org (return-path ); Thu, 19 Nov 2009 18:05:37 +0000 Message-ID: <4B0588F7.7090107@drh-consultancy.demon.co.uk> Date: Thu, 19 Nov 2009 18:05:43 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911191749.nAJHn2IT001762@fs4113.wdf.sap.corp> In-Reply-To: <200911191749.nAJHn2IT001762@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 18:05:47 -0000 Martin Rex wrote: > > >> Yes, we might be missing something else. The reason I picked the Certificate >> message is that it is dynamic size by default, so we don't have to alter >> existing data, just append. > > To me that feels very wrong to use the Certificate message. > I'm convinced that it should go into the ServerHello. I'm not > questioning that ServerHello is the correct place for all of the > cryptographic parameters _and_ the TLS extensions. > Well in terms of implementation and overhead I'd prefer that the client knows as soon as possible which method to use. The need to maintain two hash contexts (or cache some potentially long handshake messages) and always throwing one away is IMHO not trivial. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Thu Nov 19 10:45:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B423A69CA for ; Thu, 19 Nov 2009 10:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.190, 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 hjhiQlAbPp0P for ; Thu, 19 Nov 2009 10:45:47 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 54AD328C0FE for ; Thu, 19 Nov 2009 10:45:46 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAJIjgam022114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 19:45:42 +0100 (MET) From: Martin Rex Message-Id: <200911191845.nAJIjdL6005270@fs4113.wdf.sap.corp> To: noskov@microsoft.com (Nasko Oskov) Date: Thu, 19 Nov 2009 19:45:39 +0100 (MET) In-Reply-To: from "Nasko Oskov" at Nov 19, 9 01:23:41 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 18:45:48 -0000 Nasko Oskov wrote: > > Michael D'Errico wrote: > > > > Also the Certificate message is optional, so it would cause > > trouble for some cipher suites. > > Fair point. > > > > And even more importantly, there is only ServerHello sent > > when you resume an old session! > > Session resumption is already secure since it uses existing crypto state > as part of the negotiation. There are no problems in that case. I'm confused by the latter. It doesn't sound right. A resumed TLS session can certainly be reneogitated later, and of course, we neither a TLS session resume to be proxied into the reneogitation of a server, nor do we want a TLS renegotiation on a resumes session to be unprotected/insecure like in the past. Althouh TLS session resume seems to have been disabled during renegotiation by at last some implementations, it would actually the first choice if all that the client wants to do is rekeying (huge data transfers an only RC4 or 3DES ciphersuites), because it would be the most efficient. TLS session resume avoids the PKI crypto overhead of the full handshake, _but_ will derive new session keys from the master secret of the cached session plus ClientHello.Random and ServerHello.Random and reinitialize the SecurityParameters of the connection state. A client initiating a TLS renegotiation would know whether it wants to rekey (and would significantly benefit from a TLS session resume) or when it wants to change the cryptographic characteristics of the TLS session. When the Client receives a ClientHelloRequest from the server, then it doesn't know what the Server is trying to achieve by that. The most common usage scenario for TLS renegotiation seems to be delayed or on-demand authentication, and there a TLS session resume wouldn't help. But then, the server gets actually to choose whether it performs a full TLS handshake or whether it agrees to a TLS session resume proposed by the client. >From a technical point of view, a client proposing TLS resume on a client-initiated TLS renegotiation is the same as disconnecting, reconnecting and proposing TLS resume on the new connection. -Martin From noskov@microsoft.com Thu Nov 19 10:47:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A563A672F for ; Thu, 19 Nov 2009 10:47:40 -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 g-jKdohHWI+M for ; Thu, 19 Nov 2009 10:47:39 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4090E3A6962 for ; Thu, 19 Nov 2009 10:47:39 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 Nov 2009 10:47:36 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Thu, 19 Nov 2009 10:47:33 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 19 Nov 2009 10:47:31 -0800 From: Nasko Oskov To: "tls@ietf.org" Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: AQHKaLf0cVdf57VSH0Kf/9CoEm1bgpE9v8ZA Date: Thu, 19 Nov 2009 18:46:41 +0000 Deferred-Delivery: Thu, 19 Nov 2009 18:47:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: doI= BPRL Bdf/ ComJ DR5u Exje E2Q2 FuL3 GJQK Gz6k G+dp ITTD IirR I9r7 Kd4d KoBQ; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {7A2A2FD2-1F24-44B6-B52D-C3A1FDAE9188}; bgBvAHMAawBvAHYAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Thu, 19 Nov 2009 18:47:00 GMT; UgBFADoAIABbAFQATABTAF0AIABQAHIAbwBwAG8AcwBhAGwAIABmAG8AcgAgAGgAeQBiAHIAaQBkACAAcwBvAGwAdQB0AGkAbwBuACAAdQBzAGkAbgBnACAAbQBvAHMAdAAgAG8AZgAgAHQAaABlACAAaQBkAGUAYQBzAA== x-cr-puzzleid: {7A2A2FD2-1F24-44B6-B52D-C3A1FDAE9188} Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 18:47:40 -0000 Yngve N. Pettersen wrote: >Hello Nasko, > >Let me see if I read this correctly: > > - For TLS with Extensions, use the RI extension? Is that right? Or > another signaling extension? For TLS we should always be using extensions. RI is the initial proposal that I had, but if we are fixing SSLv3 I suggest we alter it a bit to allow for common code between SSLv3 and TLS. > - For SSLv3/TLS without Extensions use the special cipher. Only in this > case, or also when the Extension is used, just in case a non-Extension > server tolerates Extension (it IS known to happen occasionally), but do > understand the cipher? Ciphersuite is only used in SSLv3. I propose that if apps (mostly browsers) fall back when connecting to TLS servers that don't tolerate extensions, instead of falling back to TLS without extensions (insecure) they fall back to SSLv3 (which we should be fixing too). > - If the server understand RI, it uses that If the server is to use the TLS protocol, yes. > - If it does not understand the RI, but the cipher, send the special cer= tificate If the server has chosen the TLS protocol, don't use any of the workarounds suggested, just use RI and either allow unpatched clients or not based on configuration. >Correct so far? I hope that clarifies it. >If so, provided that this is always done for all the Client's Hellos, also >the first on the connection (I got an impression from your email that this >was not required, which could cause problems for first handshakes) I think >it should work (though some will say it is too complex, but with this kind >of legacy issues you can't fix a problem like this in a simple way). Signaling (whether with extensions or not) should be present always in initial ClientHellos. >The reason the RI/fallback must be used on the first negotiation is, aside >from the MITM attack, that I as a client need to be able to tell up front >what I am dealing with, whether to include information in the Security >information, adjust security levels, display a warning dialog, or refuse t= o >connect to an unpatched server. I can't wait for a possible renegotiation. Correct. We should be signaling on initial handshaking for sure. What changes in the renegotiation case is how the Finished message is computed. >Mike was concerned about session resume, but I do not think that is a real >issue, since we already know the parameters of the server by this time: > > - If the server is using RI, the check will be part of the Hellos > - If the server is using the fallback, we already know that it does (it > is part of the TLS Session information) and modify the Finished > calculations accordingly. > - If it is using neither, then we also know that, and does not enable > the modified Finished calculation mode. > >The S->C signaling is only needed during a full negotiation, while the =20 >C->S signaling is needed each Hello since the server might not want to >resume a session. What I was exploring is whether we can signal S->C in any other message. After trying to use the Server Finished and discussing it with Marsh, I realized that we don't prevent the attack unless we signal *before* the server generates the Server Finished. >Mike do have a point about the cipher suites that does not use >certificates. I am not too concerned about the Anonymous ciphers (they are >too vulnerable anyway), but there are IIRC several suites relying on >different key exchange methods than PKI (though not supported by Opera). That could very well be a problem that I might have missed. What I might have missed to communicate is the following main ideas: * We have to fix SSLv3 and this will require changing the Finished message calculation (either that or disable fallback to it, which is infeasible i= n the medum term) * If we were to do the SSLv3 change, to minimize changes overall, the approach for TLS could use this change and use the extension mechanism fo= r signaling only (without transporting the data). * Certificate message could be used as S->C signaling, since it is variable by default, most likely intermediate devices (firewall, IDS, so on) are not inspecting the validity of if (I doubt firewalls do chain verification) and as such it is less likely to have interop issues. We know the endpoints will handle it properly because they will be patched. = I am worried about devices that are not upgraded dropping messages because of unknown contents. Nasko From marsh@extendedsubset.com Thu Nov 19 11:02:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414B83A6873 for ; Thu, 19 Nov 2009 11:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 J7Ev1hQsxpSF for ; Thu, 19 Nov 2009 11:02:52 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 443CC3A67DD for ; Thu, 19 Nov 2009 11:02:52 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NBCHJ-000N0o-HE for tls@ietf.org; Thu, 19 Nov 2009 19:02:49 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 905D6667C for ; Thu, 19 Nov 2009 19:02:48 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX186HynAgfcqUa/0cfkeEvI8/ItMnqhF1L8= Message-ID: <4B059658.2010200@extendedsubset.com> Date: Thu, 19 Nov 2009 13:02:48 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> In-Reply-To: <4B053CF5.7000105@drh-consultancy.demon.co.uk> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:02:53 -0000 Dr Stephen Henson wrote: > > What browsers and many libraries (including OpenSSL) do in the first place is to > send an initial "version discovery" SSLv3 compatible client hello (or even > SSLv2) with the version number set to the maximum number of SSL/TLS supported. > The reply then indicates the version of SSL/TLS supported. Until that point you > don't know what the server supports. So the connection can end up talking TLS > v1.2 even though it initially sent and SSLv3 compatible client hello. So using extensions (even when both ends support TLS 1.1) would significantly change the client hello for many current clients? Yngve of Opera and Nelson of Mozilla had posted some connection logic that didn't work quite like that. But now that you mention it that is what I see from typical non-browser clients. Back to unified SSL/TLS solutions then. Looks like C->S signaling could be achieved back to SSLv2 with the magic cipher suite technique. For S->C, setting that high bit in the version field is looking not so bad now. RFC 4346: > server_version > This field will contain the lower of that suggested by the client > in the client hello and the highest supported by the server. What worries me is that a great many inspecting firewalls are going to see that and freak out because the server is replying with a version higher than the client. Perhaps those nice, friendly, and helpful networking hardware and software vendors on this list will offer some lab time to check this out? Another possibility is bit 15 of cipher_suite, assuming there will not be a need for 32769 different cipher suites before extensions become usable. - Marsh From djhopwood@googlemail.com Thu Nov 19 11:06:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655BF28C101 for ; Thu, 19 Nov 2009 11:06:23 -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 7cc3EZ5QrCdg for ; Thu, 19 Nov 2009 11:06:22 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 18EE228C104 for ; Thu, 19 Nov 2009 11:06:21 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so611561eya.51 for ; Thu, 19 Nov 2009 11:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=8TRuuCY9hh5lXesrAEqv0ExKmHGI3Sm6AXf7aIy/9RI=; b=twy5LcDunG10vRyXPtZ19PIYnXY+Inoxn9KLBJJ0mWeNirTBJ8MZRdwi59B+7k+0i+ ZAjuR5gs3Iabfe86/xgvTUMKTYgo889rZXDaQDv9dpGaCTZf3b7fSBHTkKZQtJF9Y4SE rg0lYXNu1vBUQF043DPpxPmJnoThaCgdGczjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Y6cTB0S0aGmgclOoSt0pUDsNhDUso7PsMWtBGO2GTGCcR7GPrjQ3YmTSpizhFWE0WT DU8vrcMnoVcJDWgGi+3fK7E7LYwGcdEqRpQ8PFlITIyZSjbhZYACgXS90xbibkgVOl8B SBrfI1akm+eUK/+8wcdK7TLSSNXbox46QyDGY= Received: by 10.213.1.5 with SMTP id 5mr1831226ebd.22.1258657575555; Thu, 19 Nov 2009 11:06:15 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm365869ewy.8.2009.11.19.11.06.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 11:06:13 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B059716.6010309@jacaranda.org> Date: Thu, 19 Nov 2009 19:05:58 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig200C53CF1601323418A09F4D" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:06:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig200C53CF1601323418A09F4D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nasko Oskov wrote: > David-Sarah Hopwood wrote: >> Martin Rex wrote: >>> There are going to be components out there that will not get patched.= =20 >>> They might not implement renegotiation (or have it >>> disabled) and they're therefore not even vulnerable. >>> >>> But we can not simply brick them (deny to talk SSL to them in the=20 >>> future). >>> >>> So Browsers will likely have to continue to offer an fallback to=20 >>> extension-less ClientHello. >>=20 >> This is a non-sequitur. Lenient clients don't need to send the extensi= on in the >> ClientHello of an initial handshake. Strict clients must not be able t= o talk to >> unpatched servers, by definition. >=20 > I must be misunderstanding the attack. Why is the attack not possible > even when client doesn't send the RI extension on initial handshake? Because the server knows that the connection is a renegotiation from its point of view, and therefore it rejects any handshake that doesn't contain the extension. > If the MiTM sends a client hello to the server that has no extension, t= hen > the server has no way to drop the connection. This will require a stric= t > server to prevent the attack and strict server config will not be reali= ty > for a long time. What am I missing? That, in the RI approach, strict server config is essential from the star= t. We haven't yet established whether the ability to support lenient servers= is a requirement. Eric has argued against allowing that; so have I. If lenient servers are allowed, then I think it will take *much* longer until the vulnerability is eliminated from most connections. Remember, rejecting a renegotiating ClientHello does not necessarily lead= to an interoperability failure; it only does so if the client will not reconnect. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig200C53CF1601323418A09F4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksFlx8ACgkQWUc8YzyzqAfWrwD/RKuW70bZulp/kuQanjOkiKZo 8Z0wtjIBVM3JFQ8G7gsBAJ82iafHP82VTh6nMGocuyrIDw+ZQBs2O0hB3EN90Ddk =P/AY -----END PGP SIGNATURE----- --------------enig200C53CF1601323418A09F4D-- From mike-list@pobox.com Thu Nov 19 11:14:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177FF28C107 for ; Thu, 19 Nov 2009 11:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 G-htaxmeGBBN for ; Thu, 19 Nov 2009 11:14:53 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 91F8D28C104 for ; Thu, 19 Nov 2009 11:14:52 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B96FC7F8C1 for ; Thu, 19 Nov 2009 14:14:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=SDN/lNBcqD64 T0ml8t6ErtW02EE=; b=vc+63RySM5bAP5wCFbtD6DqkiKZZp9Fy+V9uxO5/xUo8 kUCGjbbrExsU1M/GHBdnZS0MwVdBC9qodVIv97txA45+SCr/21XdAH3AsSlXrkws uXdwVSphQ0c78NBAjzODWppIMqzv35rCxgqoXn0stdLG3TWM2KMkIT6LHqsCOko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Bn6stQ KiSqFPqHgJrtuaQOAuSNAx9QqkS54lMRCPdiMMjxDpZ8I+6EZhogJ9gunTjHHR3z d5UJoIghHjPN1sSxXUTc1PENbAOcJB65492ZNpin868keFbafxrqoIfiHPcBNd7C +ADJYDzHUyCF3EMWGXhnUR5/1UoUKvd65k2eY= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B23567F8C0 for ; Thu, 19 Nov 2009 14:14:49 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 42D937F8BE for ; Thu, 19 Nov 2009 14:14:49 -0500 (EST) Message-ID: <4B059978.2010800@pobox.com> Date: Thu, 19 Nov 2009 11:16:08 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911191749.nAJHn2IT001762@fs4113.wdf.sap.corp> <4B0588F7.7090107@drh-consultancy.demon.co.uk> In-Reply-To: <4B0588F7.7090107@drh-consultancy.demon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CECC63D4-D53F-11DE-A3AE-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] The Hardware Angle X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:14:55 -0000 Dr Stephen Henson wrote: > > Well in terms of implementation and overhead I'd prefer that the client knows as > soon as possible which method to use. This is especially true for hardware. I don't think anyone would argue that firewall/monitoring devices will want to detect the patched status of clients and servers. The non-extension approach to solving this problem is infinitely better to a hardware engineer. (I design digital hardware circuits for fun[*] -- yes I know I'm a geek.) The hardware for detecting a patched client is just a few lines of Verilog code: wire [7:0] session_id_len = client_hello[34]; wire [7:0] first_cipher_hi = client_hello[37+session_id_len]; wire [7:0] first_cipher_lo = client_hello[38+session_id_len]; wire [15:0] first_cipher = {first_cipher_hi, first_cipher_lo}; wire patched_client = (first_cipher == MAGIC_CIPHER_SUITE); (I hope I got that right.) The hardware for detecting a patched server is similarly easy: wire [7:0] major_version = server_hello[0]; wire [7:0] minor_version = server_hello[1]; wire [15:0] server_version = {major_version, minor_version}; wire patched_server = (server_version >= 16'h0380); This is all purely combinational logic, i.e. it is nearly instantaneous. If our solution involves extensions or altered Certificate messages, then the hardware becomes many orders of magnitude more difficult. You require "sequential logic" which means that state machines are needed to parse through the Hello messages. Many clock cycles will be wasted, meaning that we will have significantly slowed down all secure Internet traffic. Mike [*] see http://www.digilentinc.com (contact me off-list if interested in this -- it has made me a much better software developer as well) From marsh@extendedsubset.com Thu Nov 19 11:19:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7493A6834 for ; Thu, 19 Nov 2009 11:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 5Ka26N4zGwHh for ; Thu, 19 Nov 2009 11:19:47 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 6A9703A67AF for ; Thu, 19 Nov 2009 11:19:47 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NBCXg-0003bo-QU for tls@ietf.org; Thu, 19 Nov 2009 19:19:44 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B1BC8667C for ; Thu, 19 Nov 2009 19:19:42 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19J5IM98IA8b2Ccl8crOatAi9y2CYmNa8c= Message-ID: <4B059A4E.2050703@extendedsubset.com> Date: Thu, 19 Nov 2009 13:19:42 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls >> \"tls@ietf.org\"" References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> In-Reply-To: <4B059716.6010309@jacaranda.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:19:52 -0000 David-Sarah Hopwood wrote: > > If lenient servers are allowed, then I think it will take *much* longer > until the vulnerability is eliminated from most connections. If lenient servers are not allowed, a server admin cannot patch his server until all clients have patched. The world will have long given up on renegotiation by then and just patched to disable it entirely. If lenient servers are allowed, the servers can patch right away and immediately begin protecting connections made with patched clients. This group has to quit thinking it can dictate limits on functionality in order to compel the consumers of the technology to do things your way. The world isn't exactly leaping at the chance to upgrade to each new TLS RFC you know. Trying to do that on a security fix is going to leave a particularly bad taste in people's mouths. - Marsh From djhopwood@googlemail.com Thu Nov 19 11:20:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB3B28C112 for ; Thu, 19 Nov 2009 11:20:23 -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 fJtvyD927nBL for ; Thu, 19 Nov 2009 11:20:22 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 217F63A6834 for ; Thu, 19 Nov 2009 11:20:21 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so614888eya.51 for ; Thu, 19 Nov 2009 11:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=d6ZisDKZ/L5X13l3VgZXYTl6/D/0KRPei+aGw6TFivM=; b=PB2dh7w3QFps55lT0eYu5h/p3+ut1qd6Zao/aJNKLw/doN5RosowrrhXg+Z+MWMCqA hzzHAO2Zh7rKCC2IwJaYXk6zMa1Zf5LQWs1K6CCljDlNKWR3m2A1CiTNW3yU7wpjPPaU DlfKjB8W9PbnWhcIEjM7U0ll/4NsdxQEBssi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=xilMuHKsOj1Y7/XZkn1TM06qWLcMQDkkZZ1evmMZXxdxRdHn3Onh8ubKDrQMj2DqSD XyClyqPbt2ZbTe5eEij2kyLghpN+KhE0/O7s2ixEzHFPTQmmQQoQ9Cc2nt1LJVHNqPKB 4qXpbA51GmOX9m6Fy9nGvroBms/jkSCOYttOg= Received: by 10.213.26.140 with SMTP id e12mr1868549ebc.0.1258658416300; Thu, 19 Nov 2009 11:20:16 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 10sm208438eyd.37.2009.11.19.11.20.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 11:20:15 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B059A60.9000003@jacaranda.org> Date: Thu, 19 Nov 2009 19:20:00 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> In-Reply-To: <4B059716.6010309@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF7CB0896C98C5924DF4485E9" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:20:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF7CB0896C98C5924DF4485E9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Nasko Oskov wrote: >> David-Sarah Hopwood wrote: >>> Martin Rex wrote: >>>> There are going to be components out there that will not get patched= =2E =20 >>>> They might not implement renegotiation (or have it >>>> disabled) and they're therefore not even vulnerable. >>>> >>>> But we can not simply brick them (deny to talk SSL to them in the=20 >>>> future). >>>> >>>> So Browsers will likely have to continue to offer an fallback to=20 >>>> extension-less ClientHello. >>> This is a non-sequitur. Lenient clients don't need to send the extens= ion in the >>> ClientHello of an initial handshake. Strict clients must not be able = to talk to >>> unpatched servers, by definition. >> I must be misunderstanding the attack. Why is the attack not possible >> even when client doesn't send the RI extension on initial handshake? >=20 > Because the server knows that the connection is a renegotiation from it= s > point of view, and therefore it rejects any handshake that doesn't > contain the extension. >=20 >> If the MiTM sends a client hello to the server that has no extension, = then >> the server has no way to drop the connection. This will require a stri= ct >> server to prevent the attack and strict server config will not be real= ity >> for a long time. What am I missing? >=20 > That, in the RI approach, strict server config is essential from the st= art. Point of clarification: "strict server" here means that the server does not accept *renegotiations* with an unpatched client. It still accepts initial handshakes. A "strict client", OTOH, will refuse to make even initial connections to an unpatched server. So support for lenient (as well as strict) clients is certainly necessary, but whether support for lenient servers is needed= is much less clear. > We haven't yet established whether the ability to support lenient serve= rs > is a requirement. Eric has argued against allowing that; so have I. > If lenient servers are allowed, then I think it will take *much* longer= > until the vulnerability is eliminated from most connections. >=20 > Remember, rejecting a renegotiating ClientHello does not necessarily le= ad > to an interoperability failure; it only does so if the client will not > reconnect. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigF7CB0896C98C5924DF4485E9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksFmmcACgkQWUc8YzyzqAdFxAD/eqnLB7sM3K+fecD3TLl3yFcf +Z825mYQ1pupRCUkly4A/2fr9/XHfIsawOzQbSLcHxoVQNLR/Rsi6AfInEOBUNrC =bHI8 -----END PGP SIGNATURE----- --------------enigF7CB0896C98C5924DF4485E9-- From mrex@sap.com Thu Nov 19 11:22:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA3528C0DE for ; Thu, 19 Nov 2009 11:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.064 X-Spam-Level: X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=0.185, 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 V8tn4z7SYWcd for ; Thu, 19 Nov 2009 11:22:01 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 04DE528C164 for ; Thu, 19 Nov 2009 11:22:00 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAJJLucf001071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 20:21:56 +0100 (MET) From: Martin Rex Message-Id: <200911191921.nAJJLtwF007361@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 19 Nov 2009 20:21:55 +0100 (MET) In-Reply-To: <4B059658.2010200@extendedsubset.com> from "Marsh Ray" at Nov 19, 9 01:02:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:22:02 -0000 Marsh Ray wrote: > > So using extensions (even when both ends support TLS 1.1) would > significantly change the client hello for many current clients? Yngve of > Opera and Nelson of Mozilla had posted some connection logic that didn't > work quite like that. But now that you mention it that is what I see > from typical non-browser clients. > > Back to unified SSL/TLS solutions then. > > Looks like C->S signaling could be achieved back to SSLv2 with the magic > cipher suite technique. > > For S->C, setting that high bit in the version field is looking not so > bad now. > > RFC 4346: > > server_version > > This field will contain the lower of that suggested by the client > > in the client hello and the highest supported by the server. > > What worries me is that a great many inspecting firewalls are going to > see that and freak out because the server is replying with a version > higher than the client. I'm somewhat more worried about breaking interop with SSL and TLS peers than confusing inspecting firewalls. It is the IETF that defines how TLS clients and TLS servers can negotiate a change in protocol and consensually communicate with modified semantics. If they want to filter on "signatures" of known attacks, fine, but they must not make flawed assumptions about evolvement of network or transport-level protocols. > > Perhaps those nice, friendly, and helpful networking hardware and > software vendors on this list will offer some lab time to check this out? Of course, if vendors/suppliers are listening in to this discussion, it would be interesting to hear their opinion on what kind of changes might upset their equiment! > > Another possibility is bit 15 of cipher_suite, assuming there will not > be a need for 32769 different cipher suites before extensions become usable. The ciphersuite number space is dived into three ranges: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-3 So you can not just shave off one bit at one end. Same for compression identifiers (3 ranges): http://www.iana.org/assignments/comp-meth-ids/comp-meth-ids.xhtml -Martin From marsh@extendedsubset.com Thu Nov 19 11:44:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B633A6828 for ; Thu, 19 Nov 2009 11:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 B0J1oMKDJ-5b for ; Thu, 19 Nov 2009 11:44:01 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 3DA0A3A67DB for ; Thu, 19 Nov 2009 11:44:01 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NBCv8-0002Gh-Hp for tls@ietf.org; Thu, 19 Nov 2009 19:43:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 841C0667C for ; Thu, 19 Nov 2009 19:43:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+pqbsHvm8wr6pYBbqua4EMR7aguuvcqvs= Message-ID: <4B059FFC.1000903@extendedsubset.com> Date: Thu, 19 Nov 2009 13:43:56 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911191921.nAJJLtwF007361@fs4113.wdf.sap.corp> In-Reply-To: <200911191921.nAJJLtwF007361@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:44:02 -0000 Martin Rex wrote: > Marsh Ray wrote: >> >> RFC 4346: >>> server_version >>> This field will contain the lower of that suggested by the client >>> in the client hello and the highest supported by the server. >> What worries me is that a great many inspecting firewalls are going to >> see that and freak out because the server is replying with a version >> higher than the client. > > I'm somewhat more worried about breaking interop with SSL and TLS peers > than confusing inspecting firewalls. Where that is an issue, the S->C signaling would only happen if the client requests it. Still, I do not like giving up the ability to spot a patched server talking to an unpatched client. But it may not be practical after all. > It is the IETF that defines how TLS clients and TLS servers can negotiate > a change in protocol and consensually communicate with modified > semantics. If they want to filter on "signatures" of known attacks, > fine, but they must not make flawed assumptions about evolvement > of network or transport-level protocols. No, it's not that simple in reality. >> Perhaps those nice, friendly, and helpful networking hardware and >> software vendors on this list will offer some lab time to check this out? > > Of course, if vendors/suppliers are listening in to this discussion, > it would be interesting to hear their opinion on what kind of changes > might upset their equiment! I am a little disappointed that we don't get more input from vendors discussing their real-world implementations. OpenSSL, Microsoft, Mozilla, and Opera seem to have been the best in this regard. >> Another possibility is bit 15 of cipher_suite, assuming there will not >> be a need for 32769 different cipher suites before extensions become usable. > > The ciphersuite number space is dived into three ranges: > > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-3 > > So you can not just shave off one bit at one end. OK, but there is a bit pattern that can be XORed or some other simple permutation to which can encode an unambiguous signal without losing information. Help, is there a steganographer in the house?! - Marsh From djhopwood@googlemail.com Thu Nov 19 12:29:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2863A6808 for ; Thu, 19 Nov 2009 12:29:21 -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 6qbvEK30qKx9 for ; Thu, 19 Nov 2009 12:29:20 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 30F5B3A67E3 for ; Thu, 19 Nov 2009 12:29:20 -0800 (PST) Received: by yxe30 with SMTP id 30so2852421yxe.29 for ; Thu, 19 Nov 2009 12:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=B7rzfnm6hG9Yai+kIHJI2DfCHkrfcJz6bCenXp6a9c4=; b=ohfh6YWECMUSA0BYPJJ+N3fklcdWwbTq5QsZ6gnwkwfhLhr9pRTx3CiL39YLJz4lqe MM0HKiJmH0nvqTDkaoOfJAyUtjf8hxUVWebGU2+uODXF75EWSuQNlvnSedwK0Rl89zaC ulwTQKx71DZ9qvwjx6ryuuKDBI6xwg3kNrhgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=McFhpljR/ioOfWfvePIHweuEi87u/g2lEvOWkb1UgOcK41nFcn7Rt3GwdZ6sUGHIVm jzTPt6B3/jPetmQwr26hS5wtYXbIPq43iGMpUcn6KJuCo6hkhPT638WN3rMV+lB1FgzN 7U7blfs0z3trHwGQX9fWdSfN3+FHsa+pqctQI= Received: by 10.213.23.146 with SMTP id r18mr433331ebb.74.1258662553926; Thu, 19 Nov 2009 12:29:13 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 5sm223811eyh.24.2009.11.19.12.29.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 12:29:13 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B05AA7C.2000805@jacaranda.org> Date: Thu, 19 Nov 2009 20:28:44 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7F15FDBBD09376B6EE476AE6" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:29:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F15FDBBD09376B6EE476AE6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Steve Dispensa wrote: > On 11/18/09 10:10 PM, "David-Sarah Hopwood" = > wrote: >> Falling back to SSLv3 on a renegotiating handshake is not necessary, >=20 > From the client's perspective, it's an initial negotiation, not a > renegotiation.=20 No, I was referring to handshakes that are renegotiating from the client's perspective. >> because the server needs to be patched in order for a renegotiating >> handshake to succeed. If it is patched, then it is TLS- and >> extension-tolerant. >=20 > That may be(come) true, It is true by definition, since a TLS- or extension-intolerant server wouldn't conform to the spec for the patch. > but most browsers are currently doing fallback to > SSLv3 when things go wrong during (initial) negotiation. That code is i= n the > apps, not the SSL/TLS libraries. >=20 > For that to become true, you'd have to fix all the servers to handle TL= S > (nontrivial in old code I understand) No. Servers have to be TLS-tolerant (which later SSLv3 drafts already required) and to handle one extension; not to support TLS. > *AND* you'd have to get clients to stop falling back to SSLv3. That's not correct either. Clients can continue to fall back to SSLv3 provided that they do not both fall back *and* renegotiate (from the client's point of view) on the same handshake. > They couldn't stop falling back until the need > to fall back (i.e., broken TLS server implementations) disappears, whic= h may > take a long time when you consider old code. It will take another long = time > for browsers to stop falling back. >=20 > By the way, I'm assuming requiring SSLv3 to support the extension is a > non-starter. I realize it's conceptually straightforward to add, but we= 're > talking about adding a major mechanism to the protocol and requiring it= s use > immediately and unconditionally. There's nothing particularly difficult about adding support for one extension to an SSLv3 server. The extensions spec does not make any assumptions that hold only for TLS and not SSLv3. Note that, to head off a possible misconception, we are not talking here about clients sending extensions in ClientHellos with an SSLv3 record version. The suggestion is that an SSLv3 server could send an extension in response to a ClientHello with a TLS record version. This will not cause any additional interoperability problems, and is not much more difficult than using any other signalling mechanism. --=20 avid-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig7F15FDBBD09376B6EE476AE6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksFqoMACgkQWUc8YzyzqAcfZQD/ZfhGTI7f6Ih9MbSD6nIe86PR KjEpyDniTeShK9CsMMEA+gKAtxw2zUTqgQIWuZIXyywlRj5mRplZ0VGy78o0tg1O =nzWF -----END PGP SIGNATURE----- --------------enig7F15FDBBD09376B6EE476AE6-- From stefan@aaa-sec.com Thu Nov 19 12:42:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C07D3A67E1 for ; Thu, 19 Nov 2009 12:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW7JGgxnjnL4 for ; Thu, 19 Nov 2009 12:42:57 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 948E53A67CC for ; Thu, 19 Nov 2009 12:42:57 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3281D2945AB for ; Thu, 19 Nov 2009 21:43:01 +0100 (CET) Received: (qmail 30546 invoked from network); 19 Nov 2009 20:42:52 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Nov 2009 20:42:52 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 19 Nov 2009 21:42:51 +0100 From: Stefan Santesson To: Michael D'Errico , Message-ID: Thread-Topic: [TLS] Justification for "Ugly Dirty Hack" Thread-Index: AcppWNxyukBJbVD5xkGzgvUgWe1bOQ== In-Reply-To: <4B057B8A.4000809@pobox.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Justification for "Ugly Dirty Hack" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:42:58 -0000 Michael, I find your arguments convincing. This seems to me as a more generic and reasonable approach than a special server certificate. /Stefan On 09-11-19 6:08 PM, "Michael D'Errico" wrote: > Marsh Ray wrote: >> Stefan Santesson wrote: >>> What I don't understand is the rationale for providing two solutions, when >>> one solution could work for all cases. >> >> TLS can support a nice, clean, efficient solution going forward. >> >> SSLv3 needs an ugly dirty hack, no way around it. > > This appears to be the opposition to a solution that does not use > extensions. That it is an "ugly dirty hack." Here is how I think > about it: > > We are in fact creating new versions of the protocol. But not in > the sense that the existing version numbering scheme requires, i.e. > a strict linear progression from one version to the next. > > We currently have 4 versions: SSLv3, TLS1.0, TLS1.1, TLS1.2. > > We are in a sense creating 4 new parallel versions: SSLv3p, TLS1.0p, > TLS1.1p, and TLS1.2p (p meaning patched). > > These four new versions sort of interleave into the list we already > have, thus we can't do what would normally be done to select which > version the client wants. The extension-less approach Martin is > writing up has the client include a "magic" cipher suite in its > hello message to let the server know it is patched and can therefore > negotiate one of the new "p" versions. > > If the server is unpatched, it will ignore the magic cipher suite > and continue as normal. But if it is patched, then there needs to > be an unambiguous way to signal that it has selected a "p" version. > Using the server version in the ServerHello is a natural place to > put that. > > My suggestion is to set the upper bit of the minor version field. > This provides a clear and unmistakable signal to the client, and is > completely contained within the 0x03 major version number space. Is > it a "hack", yeah, but it's entirely reasonable. > > Repurposing the Certificate message seems like WAYYYY more of a hack > than this! > > This is also entirely forward-compatible. The next published version > of TLS would be "TLS 4.0" {0x04,0x00}, which is greater than any of > the existing versions and also the "p" versions if the minor version > signals them. > > Mike > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From noskov@microsoft.com Thu Nov 19 12:56:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265B33A69EC for ; Thu, 19 Nov 2009 12:56:07 -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 9pQiBoiRbAS4 for ; Thu, 19 Nov 2009 12:56:06 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 33B783A6855 for ; Thu, 19 Nov 2009 12:56:06 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 Nov 2009 12:56:25 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.21; Thu, 19 Nov 2009 12:56:03 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 19 Nov 2009 12:56:01 -0800 From: Nasko Oskov To: "tls@ietf.org" Thread-Topic: [TLS] simplistic renego protection Thread-Index: AQHKaInFGiEOTOvqREmP25vm9DLXVpE9LikAgABcDpCAAMF4AIAAA+wA//+TmtA= Date: Thu, 19 Nov 2009 20:54:17 +0000 Deferred-Delivery: Thu, 19 Nov 2009 20:55:00 +0000 Message-ID: References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> <4B059A60.9000003@jacaranda.org> In-Reply-To: <4B059A60.9000003@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:56:07 -0000 RGF2aWQtU2FyYWggSG9wd29vZCB3cm90ZToNCj4+Pj4gVGhpcyBpcyBhIG5vbi1zZXF1aXR1ci4g TGVuaWVudCBjbGllbnRzIGRvbid0IG5lZWQgdG8gc2VuZCB0aGUgDQo+Pj4+IGV4dGVuc2lvbiBp biB0aGUgQ2xpZW50SGVsbG8gb2YgYW4gaW5pdGlhbCBoYW5kc2hha2UuIFN0cmljdCBjbGllbnRz IA0KPj4+PiBtdXN0IG5vdCBiZSBhYmxlIHRvIHRhbGsgdG8gdW5wYXRjaGVkIHNlcnZlcnMsIGJ5 IGRlZmluaXRpb24uDQo+Pj4gSSBtdXN0IGJlIG1pc3VuZGVyc3RhbmRpbmcgdGhlIGF0dGFjay4g V2h5IGlzIHRoZSBhdHRhY2sgbm90IHBvc3NpYmxlIA0KPj4+IGV2ZW4gd2hlbiBjbGllbnQgZG9l c24ndCBzZW5kIHRoZSBSSSBleHRlbnNpb24gb24gaW5pdGlhbCBoYW5kc2hha2U/DQo+PiANCj4+ IEJlY2F1c2UgdGhlIHNlcnZlciBrbm93cyB0aGF0IHRoZSBjb25uZWN0aW9uIGlzIGEgcmVuZWdv dGlhdGlvbiBmcm9tIA0KPj4gaXRzIHBvaW50IG9mIHZpZXcsIGFuZCB0aGVyZWZvcmUgaXQgcmVq ZWN0cyBhbnkgaGFuZHNoYWtlIHRoYXQgZG9lc24ndCANCj4+IGNvbnRhaW4gdGhlIGV4dGVuc2lv bi4NCj4+IA0KPj4+IElmIHRoZSBNaVRNIHNlbmRzIGEgY2xpZW50IGhlbGxvIHRvIHRoZSBzZXJ2 ZXIgdGhhdCBoYXMgbm8gZXh0ZW5zaW9uLCANCj4+PiB0aGVuIHRoZSBzZXJ2ZXIgaGFzIG5vIHdh eSB0byBkcm9wIHRoZSBjb25uZWN0aW9uLiBUaGlzIHdpbGwgcmVxdWlyZSANCj4+PiBhIHN0cmlj dCBzZXJ2ZXIgdG8gcHJldmVudCB0aGUgYXR0YWNrIGFuZCBzdHJpY3Qgc2VydmVyIGNvbmZpZyB3 aWxsIA0KPj4+IG5vdCBiZSByZWFsaXR5IGZvciBhIGxvbmcgdGltZS4gV2hhdCBhbSBJIG1pc3Np bmc/DQo+PiANCj4+IFRoYXQsIGluIHRoZSBSSSBhcHByb2FjaCwgc3RyaWN0IHNlcnZlciBjb25m aWcgaXMgZXNzZW50aWFsIGZyb20gdGhlIHN0YXJ0Lg0KPg0KPlBvaW50IG9mIGNsYXJpZmljYXRp b246ICJzdHJpY3Qgc2VydmVyIiBoZXJlIG1lYW5zIHRoYXQgdGhlIHNlcnZlciBkb2VzIG5vdA0K PmFjY2VwdCAqcmVuZWdvdGlhdGlvbnMqIHdpdGggYW4gdW5wYXRjaGVkIGNsaWVudC4gSXQgc3Rp bGwgYWNjZXB0cyBpbml0aWFsDQo+aGFuZHNoYWtlcy4NCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlm aWNhdGlvbi4gV2Ugc2VlbSB0byBkaWZmZXIgaW4gdGhlIGRlZmluaXRpb24gb2Ygc3RyaWN0DQpz ZXJ2ZXIgY29uZmlnLiBUaGlzIGNsYXJpZmllcyBpdC4NCg0KWW91IGFyZSBhc3N1bWluZyB0aGVu IHRoYXQgYWRtaW5zIHdpbGwgaGF2ZSB0byB1cGdyYWRlIGFueSBjbGllbnRzIHRoYXQgZG8NCnJl bmVnb3RpYXRpb24gYmVmb3JlIHRoZXkgdXBncmFkZSB0aGVpciBzZXJ2ZXJzLCBvdGhlcndpc2Ug dGhlcmUgd2lsbCBiZQ0KaW50ZXJvcCBwcm9ibGVtLiBBbSBJIGNvcnJlY3Q/DQpUaGlzIHdpbGwg bWVhbiB0aGF0IGFkbWlucyBmb3Igc2l0ZXMgdGhhdCByZXF1aXJlIGNsaWVudCBhdXRoZW50aWNh dGlvbiB3aWxsDQpub3QgYmUgdXBncmFkaW5nIHRoZWlyIHNlcnZlcnMgdW50aWwgdGhlaXIgZW50 aXJlIHNldCBvZiBjbGllbnRzIGhhdmUNCnBhdGNoZWQgYnJvd3NlcnMuIFRoZXJlIGlzIGFuIG9w dGlvbiB0byByZWFyY2hpdGVjdCB0aGUgc2l0ZSwgYnV0IHRoYXQgDQptaWdodCBub3QgYmUgcG9z c2libGUuDQoNCj5BICJzdHJpY3QgY2xpZW50IiwgT1RPSCwgd2lsbCByZWZ1c2UgdG8gbWFrZSBl dmVuIGluaXRpYWwgY29ubmVjdGlvbnMgdG8gYW4NCj51bnBhdGNoZWQgc2VydmVyLiBTbyBzdXBw b3J0IGZvciBsZW5pZW50IChhcyB3ZWxsIGFzIHN0cmljdCkgY2xpZW50cyBpcw0KPmNlcnRhaW5s eSBuZWNlc3NhcnksIGJ1dCB3aGV0aGVyIHN1cHBvcnQgZm9yIGxlbmllbnQgc2VydmVycyBpcyBu ZWVkZWQgaXMNCj5tdWNoIGxlc3MgY2xlYXIuDQoNCkdyZWF0ISBXZSBhcmUgaW4gY29uc2Vuc3Vz IG9uIHRoZSBjbGllbnQgZGVmaW5pdGlvbiBvZiBsZW5pZW50IGFuZCB0aGUgbmVlZA0KdG8gc3Vw cG9ydCB0aGF0Lg0KDQo+PiBXZSBoYXZlbid0IHlldCBlc3RhYmxpc2hlZCB3aGV0aGVyIHRoZSBh YmlsaXR5IHRvIHN1cHBvcnQgbGVuaWVudCANCj4+IHNlcnZlcnMgaXMgYSByZXF1aXJlbWVudC4g RXJpYyBoYXMgYXJndWVkIGFnYWluc3QgYWxsb3dpbmcgdGhhdDsgc28gaGF2ZSBJLg0KPj4gSWYg bGVuaWVudCBzZXJ2ZXJzIGFyZSBhbGxvd2VkLCB0aGVuIEkgdGhpbmsgaXQgd2lsbCB0YWtlICpt dWNoKiANCj4+IGxvbmdlciB1bnRpbCB0aGUgdnVsbmVyYWJpbGl0eSBpcyBlbGltaW5hdGVkIGZy b20gbW9zdCBjb25uZWN0aW9ucy4NCg0KVGhlcmUgc2VlbXMgdG8gYmUgMyBkaWZmZXJlbnQgd2F5 cyB0byBkZWZpbmUgdGhlIHNlcnZlciBiZWhhdmlvcjoNCiogYWxsb3cgYW55b25lDQoqIGRvbid0 IGFsbG93IHJlbmVnb3RpYXRpb24gZnJvbSB1bnBhdGNoZWQgY2xpZW50cw0KKiBkb24ndCBhbGxv dyBpbml0aWFsIG5lZ290aWF0aW9uIGZyb20gdW5wYXRjaGVkIGNsaWVudHMNCg0KV2Ugc2hvdWxk IGJlIGNsZWFyIG9uIHdoaWNoIG9uZXMgd2UgY2FsbCBzdHJpY3QgYW5kIGxlbmllbnQuDQoNCk5h c2tvDQo= From mike-list@pobox.com Thu Nov 19 12:57:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9D628C0EF for ; Thu, 19 Nov 2009 12:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 M1n7niVU8BGP for ; Thu, 19 Nov 2009 12:57:49 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id EF1D628C10A for ; Thu, 19 Nov 2009 12:57:48 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2F2F98144A for ; Thu, 19 Nov 2009 15:57:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=B/kMupKtJApa W014PiC3nQUrohc=; b=B7bXjpZ8BItO4z6wn05jY8diKTPuX6lZtmqv089xSG+U +KkoIYQGQcrWY8ynUuAlupKmjiCQLNmtlQfPXvPTN/kZ3F866QZBFpp2aLWe7C5e nNLw4p+IS1tLbfAhiCiPIMf2/sj4UeCxh4IMwI4a8VhIUDfowCLYT9+u64kl/Zo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=aVitHq 202aPPXzGkpPftsA+MioCpfudfrnLxIGypyg440CdWO4i4U7/UJ2GwS0PPA4vRRw rUoVKPZDGUbOefWfQjHytuyrpIfVkeVIDP5xd1e1D+fVX+eNqP33PWOy0RRr8DML 0X9AwIPGhfkY7FR1JxVPj6hNUZQDbczLcjlf8= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2604881449 for ; Thu, 19 Nov 2009 15:57:46 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 8451D81448 for ; Thu, 19 Nov 2009 15:57:45 -0500 (EST) Message-ID: <4B05B199.90104@pobox.com> Date: Thu, 19 Nov 2009 12:59:05 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B05AA7C.2000805@jacaranda.org> In-Reply-To: <4B05AA7C.2000805@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 3024D18A-D54E-11DE-BA23-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:57:50 -0000 David-Sarah Hopwood wrote: > > No. Servers have to be TLS-tolerant (which later SSLv3 drafts already > required) and to handle one extension; not to support TLS. When I send extensions, I send server_name, signature_algorithms, and possibly others. Saying that a server only has to support one extension is going to cause trouble. > There's nothing particularly difficult about adding support for one > extension to an SSLv3 server. The extensions spec does not make any > assumptions that hold only for TLS and not SSLv3. There are likely ZERO SSLv3 servers that support extensions, so you're asking them all to implement them. That is unreasonable when an alternative exists that doesn't require extensions. Mike From stefan@aaa-sec.com Thu Nov 19 13:09:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0AD3A680E for ; Thu, 19 Nov 2009 13:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3wHUzIcAjR0 for ; Thu, 19 Nov 2009 13:09:18 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id D0C043A67E3 for ; Thu, 19 Nov 2009 13:09:14 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5D8B028A873 for ; Thu, 19 Nov 2009 22:09:19 +0100 (CET) Received: (qmail 98143 invoked from network); 19 Nov 2009 21:09:11 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Nov 2009 21:09:11 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 19 Nov 2009 22:09:10 +0100 From: Stefan Santesson To: Nasko Oskov , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] Need for S->C signaling Thread-Index: Acpo9KyRPgf2+uHuMUmsQXxOU+h1aAAOJkXwAAvQ/Q0= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:09:18 -0000 Thanks Nasko, This is indeed a good reason. /Stefan On 09-11-19 4:32 PM, "Nasko Oskov" wrote: > Stefan Santesson wrote: >> Just a question to make sure we have accurately exhausted this aspect. >> >> Is it really necessary for the Server to signal that is is patched other than >> using a modified finished calculation if it is patched/upgraded. > > Yes. If you use the finished message, the attack is still possible. > >> One scenario could be: >> >> 1) Client use the magic cipher suite to signal that it is patched/upgraded. >> 2) Client sends a normal finished message. >> 3a) Un-patched server replies with normal finished message. >> 3b) Patched server replies with upgraded finished message. >> >> This way the client could determine whether the server is patched or not >> and act accordingly and get the security context of renegotiate from the >> patched server. > > Once the server replies with the Finished message, it would move to > connected state and the HTTP stack is clear to execute the MiTM request. As > part of developing proof of concept for our own testing, I've observed that > connecting to IIS server will send the server CCS, Finished, App data. > Even if the client were to drop the connection, the request has been > executed and attack is carried out. > >> There are probably reasons why this is not a good idea. I'm just not really >> sure what they are. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Thu Nov 19 13:24:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0A683A6851 for ; Thu, 19 Nov 2009 13:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_CODEINE=0.833] 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 5TGl0noHSpzg for ; Thu, 19 Nov 2009 13:24:00 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C91E03A672F for ; Thu, 19 Nov 2009 13:23:59 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAJLNtLN026357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 22:23:55 +0100 (MET) From: Martin Rex Message-Id: <200911192123.nAJLNh8E014666@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 19 Nov 2009 22:23:43 +0100 (MET) In-Reply-To: <4B05AA7C.2000805@jacaranda.org> from "David-Sarah Hopwood" at Nov 19, 9 08:28:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:24:00 -0000 David-Sarah Hopwood wrote: > > >> because the server needs to be patched in order for a renegotiating > >> handshake to succeed. If it is patched, then it is TLS- and > >> extension-tolerant. > > > > That may be(come) true, > > It is true by definition, since a TLS- or extension-intolerant server > wouldn't conform to the spec for the patch. Mind you, extension-tolerant isn't sufficient for TLS extension RI. MSIE8 on Windows2008 will send 4 extension already, and TLS extension RI would be the 5th. So you need to make sure that you code can weed out the TLS extension RI from anywhere within the extensions list when you're newly adding it to a codeline that doesn't have TLS extensions support yet, in order to be interoperable. Asking SSLv3 implementations to improve on their extensions-intolerance is still OK. Requiring them to implement generic TLS extensions is not, because it has nothing to do with the problem and is an unnecessary complexity for the fix. -Martin From ynir@checkpoint.com Thu Nov 19 13:42:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86193A6850 for ; Thu, 19 Nov 2009 13:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 rgAAqD1qaT7H for ; Thu, 19 Nov 2009 13:42:33 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7DE833A67A5 for ; Thu, 19 Nov 2009 13:42:32 -0800 (PST) X-CheckPoint: {4B05B847-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1983129C00D; Thu, 19 Nov 2009 23:42:25 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E898A29C002; Thu, 19 Nov 2009 23:42:24 +0200 (IST) X-CheckPoint: {4B05B843-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAJLgOGo026691; Thu, 19 Nov 2009 23:42:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 19 Nov 2009 23:42:30 +0200 From: Yoav Nir To: Nasko Oskov Date: Thu, 19 Nov 2009 23:42:22 +0200 Thread-Topic: [TLS] Need for S->C signaling Thread-Index: AcppYTF1QMw6eT5oQ16hclBjhvmd4w== Message-ID: <334EA87E-FDC3-4A45-B4EB-316A046EBFFD@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:42:33 -0000 On Nov 19, 2009, at 5:32 PM, Nasko Oskov wrote: > Stefan Santesson wrote: >> Just a question to make sure we have accurately exhausted this aspect. >>=20 >> Is it really necessary for the Server to signal that is is patched other= than=20 >> using a modified finished calculation if it is patched/upgraded. >=20 > Yes. If you use the finished message, the attack is still possible. >=20 >> One scenario could be: >>=20 >> 1) Client use the magic cipher suite to signal that it is patched/upgrad= ed. >> 2) Client sends a normal finished message. >> 3a) Un-patched server replies with normal finished message. >> 3b) Patched server replies with upgraded finished message. >>=20 >> This way the client could determine whether the server is patched or not >> and act accordingly and get the security context of renegotiate from the >> patched server. >=20 > Once the server replies with the Finished message, it would move to > connected state and the HTTP stack is clear to execute the MiTM request. = As > part of developing proof of concept for our own testing, I've observed th= at > connecting to IIS server will send the server CCS, Finished, App data. > Even if the client were to drop the connection, the request has been > executed and attack is carried out. I don't quite see why the attack still works. MITM does the handshake and forwards a partial request to the server. After= that, the MITM forwards the client's ClientHello. That ClientHello contain= s the magic cipher suite. The server sends the ServerHello, certificate, serverKeyExchange. The client thinks this is an initial handshake, so it sends a "normal" Fini= shed message. The server, however, thinks this is a re-negotiation, so it expects the mod= ified Finished message (the normal finished is only for the initial handsha= ke) So the server never replies with any CCS and Finished message.=20 But even if the server did send the CCS and Finished message, the Finished = message does not check out, so the client does not complete the request. So= where's the damage. The other attack is where the server initiates the re-negotiation with a He= lloRequest. In that case, again, the client's Finished message doesn't chec= k out, because it's calculated as an initial handshake Finished. So the ser= ver does not execute the request. So how does the attack still work? Yoav From mike-list@pobox.com Thu Nov 19 13:57:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891BA3A6852 for ; Thu, 19 Nov 2009 13:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 EBeLtmrVBOA5 for ; Thu, 19 Nov 2009 13:57:53 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 68A413A6846 for ; Thu, 19 Nov 2009 13:57:53 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A51D09F05E for ; Thu, 19 Nov 2009 16:57:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=1aMHIMKMeZAi XrcIXwwtveHul5g=; b=qCd8huVRnvlx3rii879ZGwNho6ecPr9E1O2jUDh2W5+U nR/rCL1sSupOB31XXojApmk/MCpbh6VS+P4wN9ofWtUM8FAeemDO8URurar0/tMy Bt9kDa9JFY6kA7ZXWPJddfcI2Wnu2x5jLSaiMPquHmjKMXEKNfuqeLa/MQO0afA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ZR29oR cRUf2vUp5wqLiW0Q8seRnvTRMyNGwxXpqkGuFau+eaI6wMfXWw78e55kDpUr+ggq SBZRr7ZzvvdvolHa0Q74Fa952NnUE9m2HbDoNfOSX92ylT9EhpSL+l2IQfeP9Whb EFrhYEtFKqXJCygDIwp9tyOT3s0TFuPe83R1M= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A12399F05D for ; Thu, 19 Nov 2009 16:57:49 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 2C8209F05B for ; Thu, 19 Nov 2009 16:57:48 -0500 (EST) Message-ID: <4B05BFAC.9030507@pobox.com> Date: Thu, 19 Nov 2009 13:59:08 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <334EA87E-FDC3-4A45-B4EB-316A046EBFFD@checkpoint.com> In-Reply-To: <334EA87E-FDC3-4A45-B4EB-316A046EBFFD@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 94178054-D556-11DE-87EF-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:57:54 -0000 If the server is NOT patched, the attack works. The client would be unable to distinguish patched servers from unpatched servers if there is not a ServerHello signal sent. The client needs this signal to know if it can continue all the way to Finished safely. Earlier I had proposed a signal-less scheme with a modified Finished even for initial handshakes, but the signaling is not difficult and reduces complexity quite a bit. Mike Yoav Nir wrote: > On Nov 19, 2009, at 5:32 PM, Nasko Oskov wrote: > >> Stefan Santesson wrote: >>> Just a question to make sure we have accurately exhausted this aspect. >>> >>> Is it really necessary for the Server to signal that is is patched other than >>> using a modified finished calculation if it is patched/upgraded. >> Yes. If you use the finished message, the attack is still possible. >> >>> One scenario could be: >>> >>> 1) Client use the magic cipher suite to signal that it is patched/upgraded. >>> 2) Client sends a normal finished message. >>> 3a) Un-patched server replies with normal finished message. >>> 3b) Patched server replies with upgraded finished message. >>> >>> This way the client could determine whether the server is patched or not >>> and act accordingly and get the security context of renegotiate from the >>> patched server. >> Once the server replies with the Finished message, it would move to >> connected state and the HTTP stack is clear to execute the MiTM request. As >> part of developing proof of concept for our own testing, I've observed that >> connecting to IIS server will send the server CCS, Finished, App data. >> Even if the client were to drop the connection, the request has been >> executed and attack is carried out. > > I don't quite see why the attack still works. > > MITM does the handshake and forwards a partial request to the server. After that, the MITM forwards the client's ClientHello. That ClientHello contains the magic cipher suite. > > The server sends the ServerHello, certificate, serverKeyExchange. > > The client thinks this is an initial handshake, so it sends a "normal" Finished message. > The server, however, thinks this is a re-negotiation, so it expects the modified Finished message (the normal finished is only for the initial handshake) > So the server never replies with any CCS and Finished message. > > But even if the server did send the CCS and Finished message, the Finished message does not check out, so the client does not complete the request. So where's the damage. > > > The other attack is where the server initiates the re-negotiation with a HelloRequest. In that case, again, the client's Finished message doesn't check out, because it's calculated as an initial handshake Finished. So the server does not execute the request. > > So how does the attack still work? > > Yoav From marsh@extendedsubset.com Thu Nov 19 14:29:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB64F3A683D for ; Thu, 19 Nov 2009 14:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 yRbjP68zhI5O for ; Thu, 19 Nov 2009 14:29:49 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 38A523A6835 for ; Thu, 19 Nov 2009 14:29:49 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NBFVa-000DOE-In for tls@ietf.org; Thu, 19 Nov 2009 22:29:46 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 447BE667C for ; Thu, 19 Nov 2009 22:29:45 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/TnZIKVI0F/6jWDjk4o/Zt/hpwIPkOzwc= Message-ID: <4B05C6D8.6030205@extendedsubset.com> Date: Thu, 19 Nov 2009 16:29:44 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <334EA87E-FDC3-4A45-B4EB-316A046EBFFD@checkpoint.com> In-Reply-To: <334EA87E-FDC3-4A45-B4EB-316A046EBFFD@checkpoint.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:29:50 -0000 Yoav Nir wrote: > > But even if the server did send the CCS and Finished message, the > Finished message does not check out, > so the client does not complete the request. So where's the damage. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ http://tools.ietf.org/html/rfc4346 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Fig. 1. Message flow for a full handshake The client has to send his Finished message before he sees the server's. The server executes the request when he receives Finished from the client. There is nothing later he can wait for, really. MitM can drop the server's Finished message before the client gets a chance to verify it. - Marsh From root@core3.amsl.com Thu Nov 19 16:00:01 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7D25D3A6840; Thu, 19 Nov 2009 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091120000001.7D25D3A6840@core3.amsl.com> Date: Thu, 19 Nov 2009 16:00:01 -0800 (PST) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 00:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Renegotiation Indication Extension Author(s) : E. Rescorla, et al. Filename : draft-ietf-tls-renegotiation-00.txt Pages : 10 Date : 2009-11-19 SSL and TLS renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This draft defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-renegotiation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-19155010.I-D@ietf.org> --NextPart-- From noskov@microsoft.com Thu Nov 19 16:21:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D24E3A67DA for ; Thu, 19 Nov 2009 16:21:46 -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 3-5hYRosSq9y for ; Thu, 19 Nov 2009 16:21:45 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C909C3A681A for ; Thu, 19 Nov 2009 16:21:45 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 Nov 2009 16:21:43 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.21; Thu, 19 Nov 2009 16:21:43 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 19 Nov 2009 16:21:43 -0800 From: Nasko Oskov To: Stephen Farrell Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: AQHKaM5JSzUmjMY3F0i7YWorO/+ELpE9Zx+AgAAm5ICAAADiAIAABP+A///5EoCAAJLcgP///O8Q Date: Fri, 20 Nov 2009 00:20:58 +0000 Deferred-Delivery: Fri, 20 Nov 2009 00:21:00 +0000 Message-ID: References: <4B04F92A.8050903@extendedsubset.com> <4B0572BD.5060507@cs.tcd.ie> In-Reply-To: <4B0572BD.5060507@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 00:21:46 -0000 Stephen Farrell wrote: >Nasko Oskov wrote: >>> Which leaves us with S->C signaling. Here I'm not sure we have exhauste= d all options. >>=20 >> Yes, we might be missing something else. The reason I picked the=20 >> Certificate message is that it is dynamic size by default, so we don't=20 >> have to alter existing data, just append. > >Sorry, I'm not clear on what's being proposed here. Is it: > >a) embed a new flag of some sort in a CA-issued X.509 cert >b) add an additional server-generated self-signed cert containing > a new flag of some sort >c) something else? Yes. The idea is to have an specially defined "empty" certificate that will indicate to the client support for the new running hash computation. >I think (a) would be a bad idea. Not sure about (b) either, but at least i= t >wouldn't bring a whole new bunch of parties to the table (CA product >vendors and service providers) when something quick is what's needed. (a) and (b) will be too complex of changes and unnecessary complications. Nasko From mrex@sap.com Thu Nov 19 17:29:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860A33A6A08 for ; Thu, 19 Nov 2009 17:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 NiFckFIW-u5f for ; Thu, 19 Nov 2009 17:29:11 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 6D4863A69AE for ; Thu, 19 Nov 2009 17:29:11 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAK1T64T009927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 02:29:06 +0100 (MET) From: Martin Rex Message-Id: <200911200129.nAK1T5fB003288@fs4113.wdf.sap.corp> To: noskov@microsoft.com (Nasko Oskov) Date: Fri, 20 Nov 2009 02:29:05 +0100 (MET) In-Reply-To: from "Nasko Oskov" at Nov 20, 9 00:20:58 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 01:29:12 -0000 Nasko Oskov wrote: > > Yes. The idea is to have an specially defined "empty" certificate that will > indicate to the client support for the new running hash computation. > > >I think (a) would be a bad idea. Not sure about (b) either, but at least it > >wouldn't bring a whole new bunch of parties to the table (CA product > >vendors and service providers) when something quick is what's needed. > > (a) and (b) will be too complex of changes and unnecessary complications. Somehow it seems that the discussion are diverging more and more. Personally, I'm OK with what TLS extension RI does at an abstract level. I just don't like how it is added into the existing protocols because of the interop issues of TLS extensions with existing usage scenarios. I'm getting slightly beaten up for "modifying the handshake message hash algorithm" because it is a change of the protocol and next I getting slightly beaten up for conveying this protocol change in through the ProtocolVersion server_version field. You are now proposing to put something in a list of certificates that is not a certificate, in a handshake message that is not sent in some of the handshakes to modify the message hash computation. Inserting the Finished messages as the first data before ClientHello into the handshake message hash seems problematic, because: - it doesn't work for scenarios where the client wants to use renegotiation for client identity protection and sends the next ClientHello piggy-backed on the ClientFinished message of the initial handshake. - it is much more difficult for vendors/suppliers to offer a backwards interop for renegotiation for whatever reason, if the finished messages are inserted directly following the ServerHello handshake messages, then these two problems don't exist. I'm going back to work on my I-D now. -Martin From frantz@pwpconsult.com Thu Nov 19 18:13:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5813A6A88 for ; Thu, 19 Nov 2009 18:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjlArkmXmLfb for ; Thu, 19 Nov 2009 18:13:49 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5ECAB3A67D6 for ; Thu, 19 Nov 2009 18:13:49 -0800 (PST) Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NBJ0M-0005ym-KD; Thu, 19 Nov 2009 21:13:46 -0500 Date: Thu, 19 Nov 2009 18:13:56 -0800 From: Bill Frantz To: Michael D'Errico X-Priority: 3 In-Reply-To: <4B057B8A.4000809@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79d6931f2ac6374e86469ef8e51c85c3bc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.34 Cc: tls@ietf.org Subject: [TLS] Protocol version bit to use, was Justification for "Ugly Dirty Hack" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 02:13:51 -0000 mike-list@pobox.com (Michael D'Errico) on Thursday, November 19, 2009 wrote= : >My suggestion is to set the upper bit of the minor version field. >This provides a clear and unmistakable signal to the client, and is >completely contained within the 0x03 major version number space. Is >it a "hack", yeah, but it's entirely reasonable. If I understand the minor version field correctly, there are 5 or 6 bits that are always sent as zero by all current versions of TLS/SSL. Any of them would be suitable as a S->C signal. There may be advantages to using bits other than the 0x80 bit. For example, if the 0x04 bit is available, then it could be used for the signaling requirement, leaving 0x08 and higher available for future versions of TLS. This approach would still leave a simple ordered compare available for selecting the "most recent" protocol version both ends support. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it?" -- Marcus Ranum From mrex@sap.com Thu Nov 19 18:36:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78ABA3A6839 for ; Thu, 19 Nov 2009 18:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=0.182, 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 Sccbr+lQEs87 for ; Thu, 19 Nov 2009 18:36:19 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6BE303A67A4 for ; Thu, 19 Nov 2009 18:36:19 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAK2aFCb025214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 03:36:15 +0100 (MET) From: Martin Rex Message-Id: <200911200236.nAK2aFLS007048@fs4113.wdf.sap.corp> To: frantz@pwpconsult.com (Bill Frantz) Date: Fri, 20 Nov 2009 03:36:15 +0100 (MET) In-Reply-To: from "Bill Frantz" at Nov 19, 9 06:13:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Protocol version bit to use, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 02:36:20 -0000 Bill Frantz wrote: > > mike-list@pobox.com (Michael D'Errico) on Thursday, November 19, 2009 wrote: > > >My suggestion is to set the upper bit of the minor version field. > >This provides a clear and unmistakable signal to the client, and is > >completely contained within the 0x03 major version number space. Is > >it a "hack", yeah, but it's entirely reasonable. > > If I understand the minor version field correctly, there are 5 or 6 bits > that are always sent as zero by all current versions of TLS/SSL. Any of > them would be suitable as a S->C signal. > > There may be advantages to using bits other than the 0x80 bit. For example, > if the 0x04 bit is available, then it could be used for the signaling > requirement, leaving 0x08 and higher available for future versions of TLS. > This approach would still leave a simple ordered compare available for > selecting the "most recent" protocol version both ends support. I would _strongly_ prefer if the ServerHello.server_version field would NOT be used in < or > comparisons while still carrying the S->C signal. The change in the handshake message hash algorithm for renegotiation handshakes in order to provide secure renegotiation is a protocol change that is orthogonal to the regular protocol versioning. The signal should only be used for the network encoding and the client should seperate the S->C signal from the protocol version and store them in seperate variables. In case there is another emergeny tomorrow (which I do NOT hope) and we need to fix once again severa protocol versions into the past, then shaving another bit may collide with such comparisons. Otherwise people start wondering: is { 0x83,0x00 } better or newer than { 0x03,0x03 } ? or is { 0x83,0x01 } better or newer than { 0x03,0x04 } ? Please, don't! -Martin From nelson@bolyard.me Thu Nov 19 19:03:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D013A6809 for ; Thu, 19 Nov 2009 19:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 RjzNV2W9Qh13 for ; Thu, 19 Nov 2009 19:03:26 -0800 (PST) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id C11363A67A4 for ; Thu, 19 Nov 2009 19:03:26 -0800 (PST) Received: (qmail 4569 invoked from network); 20 Nov 2009 03:03:23 -0000 Received: from unknown (24.5.142.42) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 20 Nov 2009 03:03:23 -0000 Message-ID: <4B060687.30007@bolyard.me> Date: Thu, 19 Nov 2009 19:01:27 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> In-Reply-To: <4B059716.6010309@jacaranda.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 03:03:27 -0000 On 2009-11-19 11:05 PST, David-Sarah Hopwood wrote: > Nasko Oskov wrote: >> If the MiTM sends a client hello to the server that has no extension, then >> the server has no way to drop the connection. This will require a strict >> server to prevent the attack and strict server config will not be reality >> for a long time. What am I missing? > > That, in the RI approach, strict server config is essential from the start. > > We haven't yet established whether the ability to support lenient servers > is a requirement. Eric has argued against allowing that; so have I. > If lenient servers are allowed, then I think it will take *much* longer > until the vulnerability is eliminated from most connections. I must have missed the message wherein "lenient server" was defined. Is it a server that accepts client hellos without any signal that the client has been upgraded, but merely refuses to renegotiate with such a client? IOW, is it the kind of server that numerous vendors are shipping now, that recent patches to open source have just created, one that refuses to renegotiate at all but still accepts old style client hellos? Is someone proposing to abolish them already? > Remember, rejecting a renegotiating ClientHello does not necessarily lead > to an interoperability failure; it only does so if the client will not > reconnect. By definition, the alert that rejects a renegotiating client auth (no_renegotiation) is a warning alert. It leaves the previous TLS connection and session state intact and able to continue. So IINM, it does not lead to an interoperability failure unless the client chooses to treat that alert as fatal, despite being a warning, AND refuses to reconnect. Right? From nelson@bolyard.me Thu Nov 19 19:39:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BCB3A6898 for ; Thu, 19 Nov 2009 19:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.378, 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 5DPCkdUNXHYx for ; Thu, 19 Nov 2009 19:39:06 -0800 (PST) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id 31D493A67D8 for ; Thu, 19 Nov 2009 19:39:06 -0800 (PST) Received: (qmail 10464 invoked from network); 20 Nov 2009 03:39:02 -0000 Received: from unknown (24.5.142.42) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 20 Nov 2009 03:39:02 -0000 Message-ID: <4B060EE2.7020504@bolyard.me> Date: Thu, 19 Nov 2009 19:37:06 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> <4B059A60.9000003@jacaranda.org> In-Reply-To: <4B059A60.9000003@jacaranda.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 03:39:07 -0000 On 2009-11-19 11:20 PST, David-Sarah Hopwood wrote: > David-Sarah Hopwood wrote: >> Nasko Oskov wrote: >>> If the MiTM sends a client hello to the server that has no extension, >>> then the server has no way to drop the connection. This will require >>> a strict server to prevent the attack and strict server config will >>> not be reality for a long time. What am I missing? >> >> That, in the RI approach, strict server config is essential from the >> start. > > Point of clarification: "strict server" here means that the server does > not accept *renegotiations* with an unpatched client. It still accepts > initial handshakes. If that is a "strict server", then what is a "lenient server"? Is it a vulnerable server? From mrex@sap.com Thu Nov 19 19:54:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5C93A67B0 for ; Thu, 19 Nov 2009 19:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=0.179, 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 9HYb2xVHBTGl for ; Thu, 19 Nov 2009 19:54:27 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DAB253A676A for ; Thu, 19 Nov 2009 19:54:26 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAK3sI0d006535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 04:54:18 +0100 (MET) From: Martin Rex Message-Id: <200911200354.nAK3sHqD011263@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 20 Nov 2009 04:54:17 +0100 (MET) In-Reply-To: <4B060687.30007@bolyard.me> from "Nelson B Bolyard" at Nov 19, 9 07:01:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 03:54:28 -0000 Nelson B Bolyard wrote: > > > If lenient servers are allowed, then I think it will take *much* longer > > until the vulnerability is eliminated from most connections. > > I must have missed the message wherein "lenient server" was defined. > Is it a server that accepts client hellos without any signal that the > client has been upgraded, but merely refuses to renegotiate with such a > client? > > IOW, is it the kind of server that numerous vendors are shipping now, > that recent patches to open source have just created, one that refuses to > renegotiate at all but still accepts old style client hellos? The type of (old) servers that are going to be with us for quite some time are those that either never did renegotiate where it was recently disabled. Problem is, that they leave the clients in the dark if they don't update. There is no assurance/confirmation at the protocol level that they can't be abused. > > Is someone proposing to abolish them already? I must have missed the widespread availability of patches for secure renegotiation -- or are they taking down the entire internet until further notice? ;-) > > > Remember, rejecting a renegotiating ClientHello does not necessarily lead > > to an interoperability failure; it only does so if the client will not > > reconnect. > > By definition, the alert that rejects a renegotiating client auth > (no_renegotiation) is a warning alert. It leaves the previous TLS > connection and session state intact and able to continue. So IINM, it does > not lead to an interoperability failure unless the client chooses to treat > that alert as fatal, despite being a warning, AND refuses to reconnect. > Right? In theory "no_renegotiation" alert is a warning alert. In theory a server that wants to obtain a client certificate and send a HelloRequest should treat a resulting 'no_renegotiation' alert similar to a no_certificate alert (SSLv3) or empty Certificate message. but it is probably not that simple. If the server chokes when the client denies the HelloRequest with a no_renegotiation alert and the app on top re-connects, repeating the request, then this could result in a deadly embrace. I hope the app uses a retry-counter. -Martin From djhopwood@googlemail.com Thu Nov 19 20:10:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758C23A682B for ; Thu, 19 Nov 2009 20:10:26 -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 Ws0I0yMhpsJF for ; Thu, 19 Nov 2009 20:10:24 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 189B13A6877 for ; Thu, 19 Nov 2009 20:10:20 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so740472eya.51 for ; Thu, 19 Nov 2009 20:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=9Z560hebsdoTit52HCXUN1E2NS+fE2ahr9+rq+npExg=; b=d7ePDOwQrhrmJeiqN5MyOhLQcZ3fIiaDDZYkxAPfBNqjUmy9Ij5Gk/NzemCmBOlzmA eUeoS/mkypQwos1kKaMq7fvmYe4zt5o5vT4HJxpvIFdVgnyzPaWxw7ST5rP6RetOTd4T fuwvmp5PIYkaz6MMX5VoUViVG8h4QKHDi5RnU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=ZSTABL9hQgR3RPMeZ+sM8XcEXCMpOGtT0Q8jlgCmp5I8qm9X1R4iqmuXo1CUa3BZKb E9/0wbbw0H/WnPlZIXpAcAzNtkhG49xQRdOcDqjVGew7ACnorrn45jUd8iYWhJuewwRO +Law6WIByEf9aSQ3vEVIpLVAVAVadCMt85U5c= Received: by 10.213.103.83 with SMTP id j19mr2300512ebo.30.1258690213360; Thu, 19 Nov 2009 20:10:13 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 14sm519177ewy.3.2009.11.19.20.10.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 20:10:12 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B061687.4000206@jacaranda.org> Date: Fri, 20 Nov 2009 04:09:43 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911192123.nAJLNh8E014666@fs4113.wdf.sap.corp> In-Reply-To: <200911192123.nAJLNh8E014666@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig74B856AAD2DD605C8B8530D6" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 04:10:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74B856AAD2DD605C8B8530D6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > David-Sarah Hopwood wrote: >>>> because the server needs to be patched in order for a renegotiating >>>> handshake to succeed. If it is patched, then it is TLS- and >>>> extension-tolerant. >>> >>> That may be(come) true, >> >> It is true by definition, since a TLS- or extension-intolerant server >> wouldn't conform to the spec for the patch. >=20 > Mind you, extension-tolerant isn't sufficient for TLS extension RI. I didn't say it was. What I did say, was correct and sufficient for the point at hand. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig74B856AAD2DD605C8B8530D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksGFpEACgkQWUc8YzyzqAcwBwD+Iq3Fq/D00BeSsqQrQy+vFW8Q cRrM/E82fFtyr1h7EicA/2pSS2640HsXlIX6spAh6OYItu2Mp1ix5dhWvyPGqHBU =l5tS -----END PGP SIGNATURE----- --------------enig74B856AAD2DD605C8B8530D6-- From mike-list@pobox.com Thu Nov 19 20:23:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0BE3A67EC for ; Thu, 19 Nov 2009 20:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 EAAkb0hHSwNf for ; Thu, 19 Nov 2009 20:23:28 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 556FD3A67E5 for ; Thu, 19 Nov 2009 20:23:28 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C7D98A04D2 for ; Thu, 19 Nov 2009 23:23:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=6VV3DzSzwQ/6 ICas+O/rZ1vYzW4=; b=ZjT78Qv+sldN9OXY1G+BD6fxo8jRCdYxk1TqsT+fVaq5 EELoHxBoyIkRQbXKXnrcFoezOqu+OAGp9r1PpJpRQOaapAvz4z1/nXyiITM97uw9 dqOBonkKpliTvAFmPolaBwdjBAWSlNzrFpOc+wWaOm+AabsleFqsN4eaVtXLL40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=xW1EL8 m1velH5hwjHHYSkuPvOqM+bsFyKJC05pyRV/qdqhYGSLcqvg0rHaf1fyb1DS/nSv iVxwvTQ2OG/TIL/GUBZ2O/bAQC/O7Q+YO0BvomRW01c+ukp0XEcq7mUVedjw5P6z 1m1bHHhNQK9yBxnOxPymUGTBp1Bv7imQGAOKk= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C5908A04D1 for ; Thu, 19 Nov 2009 23:23:25 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 7B9E5A04D0 for ; Thu, 19 Nov 2009 23:23:25 -0500 (EST) Message-ID: <4B061A0E.3000002@pobox.com> Date: Thu, 19 Nov 2009 20:24:46 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> <4B059A60.9000003@jacaranda.org> <4B060EE2.7020504@bolyard.me> In-Reply-To: <4B060EE2.7020504@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 724FB276-D58C-11DE-8188-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 04:23:29 -0000 Nelson B Bolyard wrote: > > ... what is a "lenient server"? > Is it a vulnerable server? Yes. Some servers apparently cannot function without renegotiation. They will need to continue providing service to unpatched clients for some amount of time and thus remain vulnerable. The solution we publish must make it impossible for a lenient- but-patched client and a lenient-but-patched server to be successfully attacked by a MitM using the renegotiation bug. Mike From nelson@bolyard.me Thu Nov 19 20:51:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851913A68A4 for ; Thu, 19 Nov 2009 20:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 3SqTE81WTzSz for ; Thu, 19 Nov 2009 20:51:35 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id A7C993A6807 for ; Thu, 19 Nov 2009 20:51:35 -0800 (PST) Received: (qmail 26641 invoked from network); 20 Nov 2009 04:51:30 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 20 Nov 2009 04:51:30 -0000 Message-ID: <4B061FDD.4090605@bolyard.me> Date: Thu, 19 Nov 2009 20:49:33 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> <4B059A60.9000003@jacaranda.org> <4B060EE2.7020504@bolyard.me> <4B061A0E.3000002@pobox.com> In-Reply-To: <4B061A0E.3000002@pobox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 04:51:36 -0000 On 2009-11-19 20:24 PST, Michael D'Errico wrote: > Nelson B Bolyard wrote: >> ... what is a "lenient server"? >> Is it a vulnerable server? > > Yes. > > Some servers apparently cannot function without renegotiation. > They will need to continue providing service to unpatched > clients for some amount of time and thus remain vulnerable. > > The solution we publish must make it impossible for a lenient- > but-patched client and a lenient-but-patched server to be > successfully attacked by a MitM using the renegotiation bug. Based on your respective most recent messages in this thread, I think you and Martin have different definitions of "lenient server". Please establish a common set of definitions. From mrex@sap.com Thu Nov 19 20:57:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD8C3A6807 for ; Thu, 19 Nov 2009 20:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=0.175, 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 enNXGvXhES+L for ; Thu, 19 Nov 2009 20:57:27 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 8357A3A67A5 for ; Thu, 19 Nov 2009 20:57:27 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAK4vKhZ015318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 05:57:20 +0100 (MET) From: Martin Rex Message-Id: <200911200457.nAK4vKq2015512@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 20 Nov 2009 05:57:19 +0100 (MET) In-Reply-To: <4B061FDD.4090605@bolyard.me> from "Nelson B Bolyard" at Nov 19, 9 08:49:33 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 04:57:28 -0000 Nelson B Bolyard wrote: > > Based on your respective most recent messages in this thread, > I think you and Martin have different definitions of "lenient server". > Please establish a common set of definitions. I'm sorry -- my fault. I was commenting your post (about the non-renego or renego-disabled servers that are going to be with us for a while leaving clients in the dark) but quoting the lenient stuff as well. -Martin From mrex@sap.com Thu Nov 19 21:01:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B650F3A6826 for ; Thu, 19 Nov 2009 21:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.078 X-Spam-Level: X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=0.171, 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 hTYS2oWIQllt for ; Thu, 19 Nov 2009 21:01:12 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 99D453A6807 for ; Thu, 19 Nov 2009 21:01:12 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAK518CB027730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 06:01:08 +0100 (MET) From: Martin Rex Message-Id: <200911200501.nAK517WH015650@fs4113.wdf.sap.corp> To: lists@drh-consultancy.demon.co.uk (Dr Stephen Henson) Date: Fri, 20 Nov 2009 06:01:07 +0100 (MET) In-Reply-To: <4B0588F7.7090107@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Nov 19, 9 06:05:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 05:01:13 -0000 Dr Stephen Henson wrote: > > Martin Rex wrote: > > > > > >> Yes, we might be missing something else. The reason I picked the Certificate > >> message is that it is dynamic size by default, so we don't have to alter > >> existing data, just append. > > > > To me that feels very wrong to use the Certificate message. > > I'm convinced that it should go into the ServerHello. I'm not > > questioning that ServerHello is the correct place for all of the > > cryptographic parameters _and_ the TLS extensions. > > > > Well in terms of implementation and overhead I'd prefer that the client > knows as soon as possible which method to use. The need to maintain two > hash contexts (or cache some potentially long handshake messages) and > always throwing one away is IMHO not trivial. This is why I favour the approach with adding the verify_data of the finished messages directly after ServerHello, because that is where the "negotiation"/signaling is completed both peers can determine how to proceed, no assumptions necessary, no keeping multiple hashes around. -Martin From djhopwood@googlemail.com Thu Nov 19 21:18:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1723A6A1C for ; Thu, 19 Nov 2009 21:18:41 -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 hkDNNgLTrJPc for ; Thu, 19 Nov 2009 21:18:40 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id CF07F3A68E6 for ; Thu, 19 Nov 2009 21:18:39 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so756494eya.51 for ; Thu, 19 Nov 2009 21:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=BQ2h2QYHCVTS1YIus0+syBgA1Hiy+Z8+geg+9SO2aQ8=; b=ACPRPwnuvLM+0R9ru84qIMEyUvKPiFrFjpx8HqwRMztN20ji9E6uOjIBGgfWWtoVbS xz/8rUIH+1ksYkXw20vcd6NDlUbZwiaqlPpREPGbvcM6KW3fnedrz95zAenRr7CPmrpq UlM9RZRhqYAIOzzFCMtaRRx7d98LxXBn4ApM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=ubYrTJpCLj+1H19UnEjMo/xb9Y0xQS3+MUTGLaUtVNn68K44LPePKDvIiVcUBFd1JJ w9PveM735PGnWYupHpzj5mdjZFQwSxL3O7HxHmRSNIGe7Ip0DiH1Npm+/EAqpUnIdQWj gGXlS8m/WAJcEuagcfItzVS6wB9u1ZqFwfQp4= Received: by 10.213.100.80 with SMTP id x16mr898890ebn.18.1258694314611; Thu, 19 Nov 2009 21:18:34 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm136817ewy.0.2009.11.19.21.18.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 21:18:33 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B062679.2020808@jacaranda.org> Date: Fri, 20 Nov 2009 05:17:45 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> <4B059A60.9000003@jacaranda.org> <4B060EE2.7020504@bolyard.me> In-Reply-To: <4B060EE2.7020504@bolyard.me> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA2F701354ED5F8DDF546B4BD" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 05:18:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2F701354ED5F8DDF546B4BD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nelson B Bolyard wrote: > On 2009-11-19 11:20 PST, David-Sarah Hopwood wrote: >> David-Sarah Hopwood wrote: >>> Nasko Oskov wrote: >=20 >>>> If the MiTM sends a client hello to the server that has no extension= , >>>> then the server has no way to drop the connection. This will require= >>>> a strict server to prevent the attack and strict server config will >>>> not be reality for a long time. What am I missing? >>> >>> That, in the RI approach, strict server config is essential from the >>> start. >> >> Point of clarification: "strict server" here means that the server doe= s=20 >> not accept *renegotiations* with an unpatched client. It still accepts= =20 >> initial handshakes. >=20 > If that is a "strict server", then what is a "lenient server"? > Is it a vulnerable server? A server that does accept initial handshakes with an unpatched client (which obviously makes it vulnerable in that case). However, a lenient server, unlike an unpatched server, will detect an attack on connections with a patched client. I believe this is not enough to consider the server to have been "fixed",= and I think it's a bad idea to end up with a subset of servers that appear to be patched, but are still vulnerable on some connections. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigA2F701354ED5F8DDF546B4BD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksGJoQACgkQWUc8YzyzqAdVvQD8CdLPB3WXvhUWuqgM3Co/cSqe pIjCo1bOkUbzl92m4KkA/3546PAVBUygJ+FRs+hqY+bM1NidvgKu7inmtO8r/Glk =mBTj -----END PGP SIGNATURE----- --------------enigA2F701354ED5F8DDF546B4BD-- From djhopwood@googlemail.com Thu Nov 19 21:41:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B1D3A692E for ; Thu, 19 Nov 2009 21:41:49 -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 BLapHwJBVwmL for ; Thu, 19 Nov 2009 21:41:48 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 5BD733A6823 for ; Thu, 19 Nov 2009 21:41:48 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so762032eya.51 for ; Thu, 19 Nov 2009 21:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=J7Dd0mugFX8pzUlzu/HCEdU6dGo7rs7UKupaR+Swyyg=; b=FPNzZtvCuWfh0uhsjzFEkj3NV81JbHY9YpJcryH+ZxOhOfvvE2KFrirEsWIEqafdeA apzznAg7HB/c4VZN1WvXxaXMDyI63sqZolJqbBZfvikJC1lJUdFLcPUdY3gIuEHqlu4K qgN7F6OkNYtl3fCHJrCOzhrE/4KqxbpOOTKd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=xBdKsaYwOn9lWsKij3HUFhSQ+nJ77jJfIW1pmdt35mdgcP9FyEQGfqxGAzIIVyGPUM xkoaPvjZG15n8z4N73321Udex6sSvyqOeGqq9YsvmKYsbPpdqHeBNiVDdw9sAsjnK42/ ugeqwQa3KKAkGCeuOuSAngbu3OLh/bwbWPNFk= Received: by 10.213.110.17 with SMTP id l17mr859318ebp.91.1258695701702; Thu, 19 Nov 2009 21:41:41 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 5sm290949eyf.8.2009.11.19.21.41.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 21:41:41 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B062BE2.305@jacaranda.org> Date: Fri, 20 Nov 2009 05:40:50 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> <4B060687.30007@bolyard.me> In-Reply-To: <4B060687.30007@bolyard.me> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig585326D40C92A3F3290237C5" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 05:41:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig585326D40C92A3F3290237C5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nelson B Bolyard wrote: > On 2009-11-19 11:05 PST, David-Sarah Hopwood wrote: >> Nasko Oskov wrote: >=20 >>> If the MiTM sends a client hello to the server that has no extension,= then >>> the server has no way to drop the connection. This will require a str= ict >>> server to prevent the attack and strict server config will not be rea= lity >>> for a long time. What am I missing? >> That, in the RI approach, strict server config is essential from the s= tart. >> >> We haven't yet established whether the ability to support lenient serv= ers >> is a requirement. Eric has argued against allowing that; so have I. >> If lenient servers are allowed, then I think it will take *much* longe= r >> until the vulnerability is eliminated from most connections. >=20 > I must have missed the message wherein "lenient server" was defined. See my other followup. > Is it a server that accepts client hellos without any signal that the > client has been upgraded, but merely refuses to renegotiate with such a= > client? >=20 > IOW, is it the kind of server that numerous vendors are shipping now, > that recent patches to open source have just created, one that refuses = to > renegotiate at all but still accepts old style client hellos? No, those are strict servers. >> Remember, rejecting a renegotiating ClientHello does not necessarily l= ead >> to an interoperability failure; it only does so if the client will not= >> reconnect. >=20 > By definition, the alert that rejects a renegotiating client auth > (no_renegotiation) is a warning alert. Yes. > It leaves the previous TLS > connection and session state intact and able to continue. So IINM, it = does > not lead to an interoperability failure unless the client chooses to tr= eat > that alert as fatal, despite being a warning, AND refuses to reconnect.= > Right? Right, although if renegotiation is being used to tell the client to use a client cert, then a client that continues with the connection will probably receive an authorization error in the application protocol, which is an interoperability failure if the client would have had the needed cert. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig585326D40C92A3F3290237C5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksGK+sACgkQWUc8YzyzqAesygD/Qn5jXRyszt5Qv8zd0opbX08v VSuloynqhrBVHMAuecUA/129kKUUQpztC2Yp1WSrQQPFO28v88Wjya7n0M1/hxEO =8UwG -----END PGP SIGNATURE----- --------------enig585326D40C92A3F3290237C5-- From djhopwood@googlemail.com Thu Nov 19 21:54:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8943B3A62C1 for ; Thu, 19 Nov 2009 21:54:09 -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 PtjuETmzR9GR for ; Thu, 19 Nov 2009 21:54:08 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 3F5513A690A for ; Thu, 19 Nov 2009 21:54:08 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so765085eya.51 for ; Thu, 19 Nov 2009 21:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=q/hAVxrrF6rJu1HLL+i2Z8fExlGKtdQrVifOjb8Y2nM=; b=WEH9bngmzbFJFUGaPNh9kLf9MH6ZywgljVDNIGpwrGNDbkLHFmcChqkEzbi63CTu14 cb1BWsCfdFVSURdllBwnRu5UvOEd0fH6rr++w1nj0OobDj7ssWGqCL9K6QDGOblNvfIN +zXkEJJjn76mmz2QsLJEB0zx9ZK8osmwe+xm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=cD92agk8NJQefHRUaYRviG2ICNu/l7E5qA7yMyKPgsF4iXV/jjwnnRMPyHgSYtDG1u eK7pF85zCJYe3megn9unvIiGhRH7/BgSBx+pA2Bwh9H1X+HYgLX+93vxte2HmrnK9JBe bDFdy/w1vdaqhiHGT/VgJcOfnCGADYj9juFyc= Received: by 10.213.0.198 with SMTP id 6mr2407135ebc.84.1258696438629; Thu, 19 Nov 2009 21:53:58 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 16sm540618ewy.10.2009.11.19.21.53.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 21:53:58 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B062EBC.90204@jacaranda.org> Date: Fri, 20 Nov 2009 05:53:00 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <4B059716.6010309@jacaranda.org> <4B059A60.9000003@jacaranda.org> <4B060EE2.7020504@bolyard.me> <4B062679.2020808@jacaranda.org> In-Reply-To: <4B062679.2020808@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig46373D0EA4B72C30A9A3B4F3" Subject: [TLS] Definition of "lenient server" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 05:54:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig46373D0EA4B72C30A9A3B4F3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Nelson B Bolyard wrote: >> On 2009-11-19 11:20 PST, David-Sarah Hopwood wrote: >>> David-Sarah Hopwood wrote: >>>> Nasko Oskov wrote: >>>>> If the MiTM sends a client hello to the server that has no extensio= n, >>>>> then the server has no way to drop the connection. This will requir= e >>>>> a strict server to prevent the attack and strict server config will= >>>>> not be reality for a long time. What am I missing? >>>> That, in the RI approach, strict server config is essential from the= >>>> start. >>> Point of clarification: "strict server" here means that the server do= es=20 >>> not accept *renegotiations* with an unpatched client. It still accept= s=20 >>> initial handshakes. >> If that is a "strict server", then what is a "lenient server"? >> Is it a vulnerable server? >=20 > A server that does accept initial handshakes with an unpatched client > (which obviously makes it vulnerable in that case). Gack, sorry, typo. A lenient server is a server that does accept *renegotiating* handshakes with an unpatched client (which obviously makes it vulnerable in that cas= e). Both lenient and strict servers accept initial handshakes from any client= =2E I don't think there is ever a reason to reject initial handshakes where n= o client certificate is used. There might be a reason to reject initial handshakes where a client cert is used, in order to prevent the variant of an attack where the client sees the renegotiation, and is unpatched. > However, a lenient > server, unlike an unpatched server, will detect an attack on connection= s > with a patched client. That is, on any connection with a patched client. > I believe this is not enough to consider the server to have been "fixed= ", > and I think it's a bad idea to end up with a subset of servers that > appear to be patched, but are still vulnerable on some connections. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig46373D0EA4B72C30A9A3B4F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksGLsQACgkQWUc8YzyzqAdOEwD/UUakt24qs8JuoDUCZeZ0ynQW nG1EWaC3Nsyn29HrNX4A/0EMktJftRdbcrwL5HY74fsp1JkO2zkXcGU08jeMyLBm =WJCg -----END PGP SIGNATURE----- --------------enig46373D0EA4B72C30A9A3B4F3-- From pgut001@wintermute01.cs.auckland.ac.nz Thu Nov 19 22:37:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB873A6909 for ; Thu, 19 Nov 2009 22:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.039 X-Spam-Level: X-Spam-Status: No, score=-4.039 tagged_above=-999 required=5 tests=[AWL=-1.440, 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 a-Q42Ssn9Qvq for ; Thu, 19 Nov 2009 22:37:58 -0800 (PST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.37]) by core3.amsl.com (Postfix) with ESMTP id D47AC3A6863 for ; Thu, 19 Nov 2009 22:37:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0367A483DD4; Fri, 20 Nov 2009 19:37:40 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTo-1i3I+drv; Fri, 20 Nov 2009 19:37:39 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 511FE483DCB; Fri, 20 Nov 2009 19:37:39 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NBN7j-0000Ct-H4; Fri, 20 Nov 2009 19:37:39 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NBN7j-0006rG-5A; Fri, 20 Nov 2009 19:37:39 +1300 From: Peter Gutmann To: mrex@sap.com, Pasi.Eronen@nokia.com In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE12B7@NOK-EUMSG-01.mgdnok.nokia.com> Message-Id: Sender: pgut001 Date: Fri, 20 Nov 2009 19:37:39 +1300 Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 06:37:58 -0000 writes: >BTW, there's another common renegotiation case where a "low-hanging fruit" >(trivial-to-implement solution known not to cause interop problems with >broken servers) exists: changing from server-only authentication to mutual >authentication (with certificate-based cipher suites). What TLS does with certificates isn't mutual authentication, it's unidirectional authentication in both directions. TLS-PSK provides true mutual authentication. So perhaps the fix is to encourage people to switch to TLS-PSK, which as a side-effect would do a great deal to address the phishing problem as well. Peter. From stefan@aaa-sec.com Thu Nov 19 22:49:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7175C3A690B for ; Thu, 19 Nov 2009 22:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBsZ7u7dfSya for ; Thu, 19 Nov 2009 22:49:37 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id AE3383A6909 for ; Thu, 19 Nov 2009 22:49:37 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1C2A429CD01 for ; Fri, 20 Nov 2009 07:49:35 +0100 (CET) Received: (qmail 30789 invoked from network); 20 Nov 2009 06:49:33 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Nov 2009 06:49:33 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 20 Nov 2009 07:49:29 +0100 From: Stefan Santesson To: Michael D'Errico , Message-ID: Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpprZtYS8qsv/xZ8kOIlYMTVsFCUQ== In-Reply-To: <4B061A0E.3000002@pobox.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 06:49:38 -0000 I fully agree, However, just because a server accepts renegotiation with an unpatched client, does not necessarily mean that the service provided over TLS is vulnerable. One example is if authentication is performed with proper channel binding in a layer above TLS and the service is provided under that security context. I second that lenient server - unpatched client must work while ensuring that lenient server - lenient client can't be abused using downgrade attacks. /Stefan On 09-11-20 5:24 AM, "Michael D'Errico" wrote: > Yes. > > Some servers apparently cannot function without renegotiation. > They will need to continue providing service to unpatched > clients for some amount of time and thus remain vulnerable. From noskov@microsoft.com Fri Nov 20 08:22:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18A03A693B for ; Fri, 20 Nov 2009 08:22:59 -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 k9i+PLaP0Jyj for ; Fri, 20 Nov 2009 08:22:59 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 0BFF53A681D for ; Fri, 20 Nov 2009 08:22:55 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Nov 2009 08:23:06 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server id 14.0.639.20; Fri, 20 Nov 2009 08:22:44 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 20 Nov 2009 08:22:44 -0800 From: Nasko Oskov To: "mrex@sap.com" Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: AQHKaYDYSzUmjMY3F0i7YWorO/+ELpE/J4lQ Date: Fri, 20 Nov 2009 16:21:11 +0000 Deferred-Delivery: Fri, 20 Nov 2009 16:22:00 +0000 Message-ID: References: from "Nasko Oskov" at Nov 20, 9 00:20:58 am <200911200129.nAK1T5fB003288@fs4113.wdf.sap.corp> In-Reply-To: <200911200129.nAK1T5fB003288@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:23:00 -0000 Martin Rex wrote: > >I'm getting slightly beaten up for "modifying the handshake message hash >algorithm" because it is a change of the protocol and next I getting >slightly beaten up for conveying this protocol change in through the >ProtocolVersion server_version field. > >You are now proposing to put something in a list of certificates that is >not a certificate, in a handshake message that is not sent in some of the >handshakes to modify the message hash computation. As far as I understand the purpose of this mailing list, it is meant to be place for people to propose ideas and discuss them. I have proposed an idea= , it is being discussed. There are pros and cons to it. Now let's try to either agree or disagree whether it is viable solution and move on, since w= e have a problem to solve. >Inserting the Finished messages as the first data before ClientHello into >the handshake message hash seems problematic, because: > > - it doesn't work for scenarios where the client wants to use > renegotiation for client identity protection and sends the > next ClientHello piggy-backed on the ClientFinished message > of the initial handshake. In this case it might indeed be a bit more work to implement it. > - it is much more difficult for vendors/suppliers to offer > a backwards interop for renegotiation for whatever reason, Backwards interop is equivalent to any other solution out there. Server wil= l only signal back to clients that have informed the server they are patched. This is true for RI and your proposal for using the version number. I don't understand why you believe it will be more difficult and there is no specific reason you are citing. I would appreciate if you are as constructive as in your previous point. >if the finished messages are inserted directly following the ServerHello >handshake messages, then these two problems don't exist. > >I'm going back to work on my I-D now. Great! I'd be glad to read it. Nasko From mike-list@pobox.com Fri Nov 20 08:39:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2893A6A1F for ; Fri, 20 Nov 2009 08:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 N4jjGrbku4oG for ; Fri, 20 Nov 2009 08:39:53 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 514D53A6A48 for ; Fri, 20 Nov 2009 08:39:53 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4C48181DF1 for ; Fri, 20 Nov 2009 11:39:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=ASU10eObDSMah5pxiZurBB1fl DE=; b=qNmgq0Uq5fCS1o59NUl/AkpwSIj6OtPRaUyAUjPWgF0lxyP2AV0fUBrto PJoJTQ7E8tBldvlvEsdaVdp/U6uZfYkPeqfSeEoDiivtL5lyIi5i8gqBqtsfihmm oQRhYy3q5vHI1OXltGrAKdbnmKU4fPDb4qbieKWQMry1KeBLSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=v8OpX7DSTYhqx143oBS YZohrHeSSiZUERVuQz9XGlJ9E5F3j7d+yy+qfXA1INKf1gehfCnn+Wj+Cn4k0jNf 7DmYi1dQNlRUz/czHAl8pl8WCs2GwmH4O5TOcwEm39IhTWwRSXO2vACGo1UXYr1q EK5fLMTZf6XfWqNuUpGmbG+8= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0606D81DF0 for ; Fri, 20 Nov 2009 11:39:50 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 5811B81DEE for ; Fri, 20 Nov 2009 11:39:49 -0500 (EST) Message-ID: <4B06C6A9.3080508@pobox.com> Date: Fri, 20 Nov 2009 08:41:13 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 5229D410-D5F3-11DE-931A-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] Updated test server X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:39:54 -0000 I have updated my server at https://www.mikestoolbox.net to support the upcoming draft from Martin Rex. Here are the particulars: - client adds a "magic" cipher suite to its list of cipher suites in the ClientHello message as a signal to the server that it supports secure renegotiation. the code point for testing is 0xBFFF. the client MAY put the magic cipher suite anywhere in the list though it is RECOMMENDED that it be first to aid in the quick detection of patched clients by monitoring devices. - server looks for "magic" cipher suite in client's cipher suite list. it may be anywhere in the list and the server MUST check the entire list - server proceeds as normal except that when composing the ServerHello message, the high bit of the server version is set to one. this is only a signal to the client; the version is not changed. notably the record layer version MUST NOT have the high bit set. - the server then adds the previous verify_data from the prior handshake (if any) to the running hash of the handshake messages. this data MUST follow the ServerHello message. the client verify_data is added first, followed by the server verify_data. if this is an initial handshake, the data is empty, but if it is a renegotiation the data will be 72 bytes for SSLv3 or 24 bytes for all versions of TLS (unless TLS 1.2 is used with a cipher suite that changes the default length of the verify_data). - the client checks for the top bit of the ServerHello version being set to 1 and if it is adds the verify_data from the previous handshake to the running handshake messages hash immediately after ServerHello. the client verify_data is added first followed by the server's verify_data. the high bit of the version is reset to zero when used for the record layer version Mike From mike-list@pobox.com Fri Nov 20 08:46:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6E83A69F2 for ; Fri, 20 Nov 2009 08:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 5OwaAqz3of0k for ; Fri, 20 Nov 2009 08:46:39 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 1C66D3A6973 for ; Fri, 20 Nov 2009 08:46:39 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7056081EA1 for ; Fri, 20 Nov 2009 11:46:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=FUqL9gUyzJYF 7wxgy7ntPNHr7Gc=; b=VyN6Z+AaR9QpDpRk+EomylOwpFLesxeTGbkEftpjM3XW jZfsDEdApcD+00qSHpdOpaIYLE1vR3wTBMOk2kXaVwE8/hhV5EfYKjSv0CVYGRWk /2qxEi3W1eB422twXsjhNYtld/nn5EmhThz8XrP+bAUnH8JTO8Zp6h29fhIkdj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=qTr+oZ DJUdv0KFkV4N92vmjsRZsUmG99NE7FnTAssxw9kGJ46JTiIoivqIyh1p0IfklhRJ vaLN/FcLmA+YAcRIPc0r+ycNbldNsYNnKaLcA/rtlFLy1uIeo8CtN6nqLOlnHmEM Yhwk9KCQsns/iKP5hW2dwfnzQAbAYjuzaNrQ4= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2F8F481E9F for ; Fri, 20 Nov 2009 11:46:26 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 605F581E9E for ; Fri, 20 Nov 2009 11:46:25 -0500 (EST) Message-ID: <4B06C835.9070802@pobox.com> Date: Fri, 20 Nov 2009 08:47:49 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B06C6A9.3080508@pobox.com> In-Reply-To: <4B06C6A9.3080508@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 3E4CC9EC-D5F4-11DE-931A-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Updated test server X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:46:40 -0000 Just to clarify one thing, it is the top bit of the major version number that is being set, not of the minor version that I had been advocating. Martin has convinced me that this is better. Mike Michael D'Errico wrote: > I have updated my server at https://www.mikestoolbox.net to > support the upcoming draft from Martin Rex. Here are the > particulars: > > - client adds a "magic" cipher suite to its list of > cipher suites in the ClientHello message as a signal > to the server that it supports secure renegotiation. > the code point for testing is 0xBFFF. the client > MAY put the magic cipher suite anywhere in the list > though it is RECOMMENDED that it be first to aid in > the quick detection of patched clients by monitoring > devices. > > - server looks for "magic" cipher suite in client's > cipher suite list. it may be anywhere in the list > and the server MUST check the entire list > > - server proceeds as normal except that when composing > the ServerHello message, the high bit of the server > version is set to one. this is only a signal to the > client; the version is not changed. notably the > record layer version MUST NOT have the high bit set. > > - the server then adds the previous verify_data from the > prior handshake (if any) to the running hash of the > handshake messages. this data MUST follow the > ServerHello message. the client verify_data is added > first, followed by the server verify_data. if this is > an initial handshake, the data is empty, but if it is > a renegotiation the data will be 72 bytes for SSLv3 or > 24 bytes for all versions of TLS (unless TLS 1.2 is > used with a cipher suite that changes the default > length of the verify_data). > > - the client checks for the top bit of the ServerHello > version being set to 1 and if it is adds the verify_data > from the previous handshake to the running handshake > messages hash immediately after ServerHello. the client > verify_data is added first followed by the server's > verify_data. the high bit of the version is reset to > zero when used for the record layer version > > Mike From mike-list@pobox.com Fri Nov 20 09:57:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD3A3A684E for ; Fri, 20 Nov 2009 09:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 nRBpfSV6byVL for ; Fri, 20 Nov 2009 09:57:45 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 7AD7E3A6825 for ; Fri, 20 Nov 2009 09:57:45 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 8857AA0101 for ; Fri, 20 Nov 2009 12:57:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=09mjDy8gFGPwA3Vsn0UrwW6yR lA=; b=AdBp5UdAxR99vzCHPQR9Wk5CWXrQYpzF3oGHw7waoFQFNy0gAvCoDi/Cz NHqJYeqb6840HJTb1C2Vp+d0e760SysjEUzZ5BdeNqLb5iLPhVjSaJTWHJuMBx0b CAPwm1maj1VI2eAJvyEWC5UUdW66SXGtD6JXUzBScxFQzn546Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=BnXVBlEFDxEwCUQrPYA 8kzKJJsJofyOIhPohv/D2Hj6ovuXMHOSSmGlby9og2b81CtUKw9iz6C46nDCTZpS LBryd7i5RzFftMThoGFWyo0OAtDFf2nLOgFatAUH2pYPSoR/2bLQZ1jMffzEvPhg sNhxSOVrD+nowQc6ZR/AWAK4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 85C20A0100 for ; Fri, 20 Nov 2009 12:57:42 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 389BCA00FF for ; Fri, 20 Nov 2009 12:57:41 -0500 (EST) Message-ID: <4B06D8EA.10001@pobox.com> Date: Fri, 20 Nov 2009 09:59:06 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 3331E498-D5FE-11DE-A2B9-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] Interesting client behavior X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 17:57:46 -0000 I have noticed over the past couple days that there has been a change in the "signature" of clients connecting to my test server. You can tell by the sequence of connections which browser it is in many cases. However a new pattern appeared in which a client asks for the home page using TLS 1.0, and then uses SSLv3 to fetch favicon.ico. I won't mention which one it is, but it's the most recent version of that browser. I wonder if this is the result of changes made to address the renegotiation problem.... Mike From mrex@sap.com Fri Nov 20 09:58:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D65B3A68CF for ; Fri, 20 Nov 2009 09:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.781 X-Spam-Level: X-Spam-Status: No, score=-5.781 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 v8EkIxezH4GE for ; Fri, 20 Nov 2009 09:58:23 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 65F623A67A7 for ; Fri, 20 Nov 2009 09:58:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAKHwJf1001737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 18:58:19 +0100 (MET) From: Martin Rex Message-Id: <200911201758.nAKHwIWY014894@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Fri, 20 Nov 2009 18:58:18 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30FE12B7@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 18, 9 08:02:47 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 17:58:24 -0000 Pasi.Eronen@nokia.com wrote: > > BTW, there's another common renegotiation case where a "low-hanging > fruit" (trivial-to-implement solution known not to cause interop > problems with broken servers) exists: changing from server-only > authentication to mutual authentication (with certificate-based > cipher suites). > > In this case, the client could include a magic "This is a > renegotiation, but with same server certificate" cipher suite in the > renegotiation client hello, and verify that the server certs in the old > and new sessions are identical (bitwise). This would be just a magic > cipher suite number: no other on-the-wire changes, and no changes to > Finished message calculations. But the server would know this > renegotiation is secure, and could proceed even if it prohibited > "old-style" insecure renegotiation. When there really is a desire to add a few simple signals in a (probably) fully backwards compatible fashion into all existing TLS&SSL protocols through magic ciphersuite, Then I would like to suggest the following approach: - have an entire range (set of 256 ciphersuites) assigned for this purpose (e.g. first byte 190/0xBE or 191/0xBF ) - use the low byte of this range as a bitfield of 8-bits for signaling that can be independently assigned by TLS WG / IANA - require this magic ciphersuite to be first in the cipher_suites list of the ClientHello if this signaling facility is to be used - require the Server to NOT ever negotiate a ciphersuite from this range i.e. remove it from the list when it appears first in ClientHello.cipher_suites and do not pass it on to functions that determine a common cipher suite with the client. - strongly recommend clients and servers to filter this magic ciphersuite range from normal cipher suite configuration APIs -Martin From mrex@sap.com Fri Nov 20 10:28:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B603A6919 for ; Fri, 20 Nov 2009 10:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.078 X-Spam-Level: X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=0.171, 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 1s9-YUZcSu2X for ; Fri, 20 Nov 2009 10:28:46 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 857133A68DD for ; Fri, 20 Nov 2009 10:28:46 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAKISOLD016112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 19:28:24 +0100 (MET) From: Martin Rex Message-Id: <200911201828.nAKISN6Y017007@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Fri, 20 Nov 2009 19:28:23 +0100 (MET) In-Reply-To: <4AF9D674.6010500@stpeter.im> from "Peter Saint-Andre" at Nov 11, 9 06:09:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: [TLS] RC4+3DES rekeying - long-lived TLS connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:28:47 -0000 Peter Saint-Andre wrote: > > ... For example in XMPP > we use long-lived TCP connections and, on top of those, long-lived XML > streams that can be TLS-protected. In practice, for server-to-server > federation (and even for client-to-server communication) those > connections might be up for days, weeks, even months. At this point the > handling of long-lived XML streams is unspecified, but I would expect > most XMPP servers to terminate the connection and force the other party > to reconnect. There was a discussion around long-lived SSL connections and reasons for rekeying, e.g. using TLS renegotiation on mogul-open. If you're using ciphersuites with RC4 or 3DES encryption algorithms, you probably should not use such connections for prolonged times or huge amounts of data without rekeying (see below). The other issue: if you're authenticating such a connection once based on X.509 certificates and leave it open for month, you might want to talk to the PKIX folks about this. They might feel uneasy if you happily continue to communicate based on an authentication that was weeks or months in the past and do not care at all the authentication cert may have long expired or been revoked in the meantime. (I'm not a crypto-guy, so I'm just quoting this:) : Subject: Re: DES & renegotiation : Date: Thu, 19 Nov 2009 17:08:36 -0800 : From: Geoff Keating : : : For an 64-bit block cipher, at 2^32 blocks (32Gbytes), there's about a : 40% chance of a collision. If you prefer your cryptosystems to have : more like a 1-in-a-million chance of leaking information, you'd need to : re-key every 48Mbytes or so. (For 128-bit blocks a 1-in-a-million : chance requires petabytes of data.) : : Most web servers on the visible Internet do support AES; in fact, well : over half support TLS_DHE_RSA_WITH_AES_256_CBC_SHA (although among the : most popular servers, the non-DHE AES variants are chosen more often). : When asking servers to negotiate a cipher out of a fairly long list, : I found: : : 71% AES : 25% RC4 : 4% 3DES : (values add to 100% only because of rounding) : : A quick survey of 30 randomly-chosen servers that chose 3DES indicated : that most were running Apache 1.3.x with a variety of older OpenSSL : versions, the most recent being 0.9.6i. A few were running IIS/6.0. -Martin PS: WinXP and Win2K3 do not support AES ciphersuites. Btw. WinXP was shipped with new NetBooks well into 2009. From djhopwood@googlemail.com Fri Nov 20 10:41:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1CB3A68D1 for ; Fri, 20 Nov 2009 10:41:48 -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 aGvWeIgnVHd2 for ; Fri, 20 Nov 2009 10:41:37 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 5A1B93A6920 for ; Fri, 20 Nov 2009 10:41:37 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so957265eya.51 for ; Fri, 20 Nov 2009 10:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=9i0+mCD+LSL4+Df5NjAy5ArQ6urxZm6TAamavgB8RXk=; b=moOPK7xX6bLQxZdNWkmOew77GAZB9UppjqeP//b0RN3ao2msUFT4v4fXGw5ddHlkDI xugImQkwmfNgtHCHIpfwEHrS2zbq+a/MAfg4/jsU+AOPhCBfm/w8ov0KlEGFg2ovozbE +G6to6cqp+M9Jiep/kp9WfELlIVkbvps6aKLM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=T+wdP3hJaPCNXPHLdrWB3GfBaPapjOiqsT4E9Irz8lucnNpgBvsyGiE5Op8/Jz2Awc cMyPTeF8bH0rbSUxong+DOdnzJISy1wgDJ5UcLicBLBuUSRyz9eJd1kUENiuNoSEr90N kDeJIvrvmvR/Hw7TEYY5Yt1xfR7VaTalot9h8= Received: by 10.213.96.6 with SMTP id f6mr1648169ebn.31.1258742491374; Fri, 20 Nov 2009 10:41:31 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm418450ewy.8.2009.11.20.10.41.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Nov 2009 10:41:29 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B06E2D7.2040302@jacaranda.org> Date: Fri, 20 Nov 2009 18:41:27 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig37F3DA455134A47E21984285" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:41:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig37F3DA455134A47E21984285 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stefan Santesson wrote: > On 09-11-20 5:24 AM, "Michael D'Errico" wrote: >=20 >> Some servers apparently cannot function without renegotiation. >> They will need to continue providing service to unpatched >> clients for some amount of time and thus remain vulnerable. > > I fully agree, >=20 > However, just because a server accepts renegotiation with an unpatched > client, does not necessarily mean that the service provided over TLS is= > vulnerable. >=20 > One example is if authentication is performed with proper channel bindi= ng in > a layer above TLS and the service is provided under that security conte= xt. I'm skeptical. How can "proper channel binding" be done correctly in a layer above TLS, if the TLS library merges renegotiated sessions? Since the session merging will result in the client and server's state at the higher layer(s) being out of sync, nothing can be assumed about the correct functioning of those layers. > I second that lenient server - unpatched client must work while ensurin= g > that lenient server - lenient client can't be abused using downgrade > attacks. Obviously *if* lenient servers are supported, then we need to make sure that lenient patched server - lenient patched client connections are secure. But I remain unconvinced that lenient servers need to be supporte= d. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig37F3DA455134A47E21984285 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksG4tgACgkQWUc8YzyzqAep3wD/Yi11DHZEkjmXVM+6vENwEZv7 BnYYnsmK/9QL9cRRX4gA/3f+fKENy2PuXRWQ02Ss2tTc5nuhYIHYq2fI+mtrmXa0 =Ggqq -----END PGP SIGNATURE----- --------------enig37F3DA455134A47E21984285-- From lists@drh-consultancy.demon.co.uk Fri Nov 20 10:48:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32DF3A67AA for ; Fri, 20 Nov 2009 10:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 KinwXcJKthp9 for ; Fri, 20 Nov 2009 10:48:17 -0800 (PST) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by core3.amsl.com (Postfix) with ESMTP id 0BB2C3A66B4 for ; Fri, 20 Nov 2009 10:48:16 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:52987 helo=[192.168.7.8]) by relay05.mail.eu.clara.net (relay.clara.net [213.253.3.45]:10587) with esmtpa (authdaemon_plain:drh) id 1NBYWi-0008KI-HR (Exim 4.69) for tls@ietf.org (return-path ); Fri, 20 Nov 2009 18:48:12 +0000 Message-ID: <4B06E474.9020209@drh-consultancy.demon.co.uk> Date: Fri, 20 Nov 2009 18:48:20 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:48:18 -0000 Just had a crazy idea for S->C signaling: ServerHello contains the MAGIC value in the CipherSuite indicator: we know this can never happen by accident. The real ciphersuite indicator is placed elsewhere, e.g. part of session ID. Session ID definition slightly modified to permit 34 bytes instead of 32. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Fri Nov 20 10:53:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB22C3A682F for ; Fri, 20 Nov 2009 10:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.167, 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 hbcoKRkwSlGK for ; Fri, 20 Nov 2009 10:53:21 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E6D5A3A677E for ; Fri, 20 Nov 2009 10:53:20 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAKIrGhE009298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 19:53:16 +0100 (MET) From: Martin Rex Message-Id: <200911201853.nAKIrF53018260@fs4113.wdf.sap.corp> To: lists@drh-consultancy.demon.co.uk (Dr Stephen Henson) Date: Fri, 20 Nov 2009 19:53:15 +0100 (MET) In-Reply-To: <4B06E474.9020209@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Nov 20, 9 06:48:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:53:21 -0000 Dr Stephen Henson wrote: > > Just had a crazy idea for S->C signaling: > > ServerHello contains the MAGIC value in the CipherSuite indicator: > we know this can never happen by accident. The real ciphersuite > indicator is placed elsewhere, e.g. part of session ID. > Session ID definition slightly modified to permit 34 bytes > instead of 32. Signaling through ciphersuite ID in ServerHello should work. Middle Boxes may still be confused. But I would definitely _NOT_ touch the session ID, in particular not make it longer. Since the signaling through ciphersuite ID is non-ambiguous, we could just re-purpose a part of Server.Random. -Martin From marsh@extendedsubset.com Fri Nov 20 11:00:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1333A6821 for ; Fri, 20 Nov 2009 11:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 LKqlJpYtZULc for ; Fri, 20 Nov 2009 11:00:11 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 76BDA3A66B4 for ; Fri, 20 Nov 2009 11:00:11 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NBYiG-000B4N-Av; Fri, 20 Nov 2009 19:00:08 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1E5E7667C; Fri, 20 Nov 2009 19:00:04 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19rBbyfBtvHSiqg5krZxBd3HxBoto0eysg= Message-ID: <4B06E734.1080500@extendedsubset.com> Date: Fri, 20 Nov 2009 13:00:04 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dr Stephen Henson References: <4B06E474.9020209@drh-consultancy.demon.co.uk> In-Reply-To: <4B06E474.9020209@drh-consultancy.demon.co.uk> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 19:00:12 -0000 Dr Stephen Henson wrote: > Just had a crazy idea for S->C signaling: > > ServerHello contains the MAGIC value in the CipherSuite indicator: we know this > can never happen by accident. The real ciphersuite indicator is placed > elsewhere, e.g. part of session ID. Session ID definition slightly modified to > permit 34 bytes instead of 32. I like it. For reference: http://tools.ietf.org/html/rfc2246 > struct { > ProtocolVersion server_version; > Random random; > SessionID session_id; > CipherSuite cipher_suite; > CompressionMethod compression_method; > } ServerHello; Is changing SessionID from > opaque SessionID<0..32>; to 34 bytes any less-breaking of a change than simply changing the length of the ServerHello to make it a proper field? Maybe, I dunno. What if the magic cipher_suite value signals that the acutal cipher_suite value is stored in the top two bytes of random? If anything actually cares about the GMT, he can fill those in with his own. - Marsh From mrex@sap.com Fri Nov 20 11:22:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA4728C0E9 for ; Fri, 20 Nov 2009 11:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.164, 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 IWa6aswZ1D5C for ; Fri, 20 Nov 2009 11:22:13 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D6C9828C0F1 for ; Fri, 20 Nov 2009 11:21:46 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAKJLgfC020121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 20:21:42 +0100 (MET) From: Martin Rex Message-Id: <200911201921.nAKJLfcs020068@fs4113.wdf.sap.corp> To: lists@drh-consultancy.demon.co.uk Date: Fri, 20 Nov 2009 20:21:41 +0100 (MET) In-Reply-To: <200911201853.nAKIrF53018260@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 20, 9 07:53:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 19:22:13 -0000 Actually we could use your idea for a more symmetric signaling! Stephen, I REALLY like this idea! Since there are people that didn't like the gmt_unix_time in Random anyway, we could just re-purpose it entirely. Add a single magic ciphersuite as first(!) in ClientHello.cipher_suites and then the field "ClientRandom.gmt_unix_time" must be interpreted ClientHello.Random = { uint16 field_of_flags uint16 reserved opaque random_bytes[28] } And when the server sees that magic cipher suite and implements this protocol extension, then it will return the magic cipher suite as negotiated ServerHello.cipher_suite and then the definition of the ServerHello.Random will be this: ServerHello.Random = { uint16 field_of_flags CipherSuite cipher_suite /* real negotiated cipher_suite */ opaque random_bytes[28] } Those implementors who want to keep a gmt_unix_time in their Random to provide uniqueness, will need to put it somewhere into random_bytes, like in the first 4 octets of that element. This would give us 16 free bits for bi-directional signaling in ClientHello and ServerHello at the cost of 2 Bytes in ClientHello. The fun part: these bit-flags are not only protected by the handshake message hash, they actually go into the PRF for the session keys. Some kind of extra protection. :) -Martin PS: the session ID is used by servers to manage their cache and may also be used by server-side load-balancers. the session ID is only "random"-equivalent for the client From uri@ll.mit.edu Fri Nov 20 11:22:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1122B3A6962 for ; Fri, 20 Nov 2009 11:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf8UDwCy1QZa for ; Fri, 20 Nov 2009 11:22:54 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 2D4183A6857 for ; Fri, 20 Nov 2009 11:22:53 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAKJMl9N018287 for ; Fri, 20 Nov 2009 14:22:47 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAA5CaGk0; Fri Nov 20 14:09:18 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Fri, 20 Nov 2009 14:09:18 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Fri, 20 Nov 2009 14:09:04 -0500 Thread-Topic: [TLS] TLS Protocol Version Thread-Index: Acppq/7ljT9e617ERRKsW3t1M/vDawAaPX7G Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7ECACE3EB@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] TLS Protocol Version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 19:22:55 -0000 SSBkb24ndCBrbm93IGlmIFBTSyBjYW4gZmx5IGluIHRoZSB3aWRlciBJbnRlcm5ldCBlbnZpcm9u bWVudCAtIGJ1dCBQZXRlciBpcyBxdWl0ZSBjb3JyZWN0IHJlZ2FyZGluZyBtdXR1YWwgYXV0aGVu dGljYXRpb24gYW5kIGl0cyBhYnNlbmNlIHdoZW4gY2VydHMgYXJlIHVzZWQuIEl0IHdvdWxkIGJl IGEgZ29vZCBpZGVhIHRvIGluY29ycG9yYXRlIG11dHVhbCBhdXRoIChhc3N1bWluZyB0aGlzIHBy b3RvY29sIGNoYW5nZSBjb3VsZCBiZSAiZGlnZXN0ZWQiKS4NCg0KDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQpGcm9tOiB0bHMtYm91bmNlc0BpZXRmLm9yZyA8dGxzLWJvdW5jZXNAaWV0 Zi5vcmc+DQpUbzogbXJleEBzYXAuY29tIDxtcmV4QHNhcC5jb20+OyBQYXNpLkVyb25lbkBub2tp YS5jb20gPFBhc2kuRXJvbmVuQG5va2lhLmNvbT4NCkNjOiB0bHNAaWV0Zi5vcmcgPHRsc0BpZXRm Lm9yZz4NClNlbnQ6IEZyaSBOb3YgMjAgMDE6Mzc6MzkgMjAwOQpTdWJqZWN0OiBSZTogW1RMU10g VExTIFByb3RvY29sIFZlcnNpb24NCg0KPFBhc2kuRXJvbmVuQG5va2lhLmNvbT4gd3JpdGVzOg0K DQo+QlRXLCB0aGVyZSdzIGFub3RoZXIgY29tbW9uIHJlbmVnb3RpYXRpb24gY2FzZSB3aGVyZSBh ICJsb3ctaGFuZ2luZyBmcnVpdCINCj4odHJpdmlhbC10by1pbXBsZW1lbnQgc29sdXRpb24ga25v d24gbm90IHRvIGNhdXNlIGludGVyb3AgcHJvYmxlbXMgd2l0aA0KPmJyb2tlbiBzZXJ2ZXJzKSBl eGlzdHM6IGNoYW5naW5nIGZyb20gc2VydmVyLW9ubHkgYXV0aGVudGljYXRpb24gdG8gbXV0dWFs DQo+YXV0aGVudGljYXRpb24gKHdpdGggY2VydGlmaWNhdGUtYmFzZWQgY2lwaGVyIHN1aXRlcyku DQoNCldoYXQgVExTIGRvZXMgd2l0aCBjZXJ0aWZpY2F0ZXMgaXNuJ3QgbXV0dWFsIGF1dGhlbnRp Y2F0aW9uLCBpdCdzDQp1bmlkaXJlY3Rpb25hbCBhdXRoZW50aWNhdGlvbiBpbiBib3RoIGRpcmVj dGlvbnMuICBUTFMtUFNLIHByb3ZpZGVzIHRydWUNCm11dHVhbCBhdXRoZW50aWNhdGlvbi4gIFNv IHBlcmhhcHMgdGhlIGZpeCBpcyB0byBlbmNvdXJhZ2UgcGVvcGxlIHRvIHN3aXRjaCB0bw0KVExT LVBTSywgd2hpY2ggYXMgYSBzaWRlLWVmZmVjdCB3b3VsZCBkbyBhIGdyZWF0IGRlYWwgdG8gYWRk cmVzcyB0aGUgcGhpc2hpbmcNCnByb2JsZW0gYXMgd2VsbC4NCg0KUGV0ZXIuDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0K VExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From mike-list@pobox.com Fri Nov 20 12:10:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4670628C134 for ; Fri, 20 Nov 2009 12:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 HUtzGwZyfmCF for ; Fri, 20 Nov 2009 12:10:06 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id DAD3F3A6965 for ; Fri, 20 Nov 2009 12:10:04 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7103E8148C for ; Fri, 20 Nov 2009 15:10:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=3taDIZee8SPq lrZiibxHd76Vjvg=; b=oETcuxSHGuCmELLtrOPCi4EqsVlm7pDbqkKGTt9+ge0t Yp3xqVJROy5GEW9RSDG7wzz8TFtrE2qnJUR10H6m4zUPKCprKOKe8cvP3Rt1035I Y+/+OgEnCF8UiBy1ogtrVZkJPAs66zRY6vYtkcpV7BMxcJS+Djy6L5wJ/HvEn/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=pJYBHH M95taba/n9ehUTiVMtD+AA8RRpEx3ZOvMAC3PL/6ttvsb5UhOiC8bjIFf4N6bE14 t9roxhegNeHSI+3aQhcK7beaEwm4NI2lWctUCSF13sZF0NWn1vGaI57Zqf/r3WMX bfQNgYATL6DCfaXwvxXmZU9JjTxTgKKVyOhMo= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 45BCD8148B for ; Fri, 20 Nov 2009 15:10:01 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id B9DF88148A for ; Fri, 20 Nov 2009 15:10:00 -0500 (EST) Message-ID: <4B06F7ED.3000601@pobox.com> Date: Fri, 20 Nov 2009 12:11:25 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911201921.nAKJLfcs020068@fs4113.wdf.sap.corp> In-Reply-To: <200911201921.nAKJLfcs020068@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: AF0F3298-D610-11DE-BFB9-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:10:09 -0000 I agree that something along these lines might be an improvement. I found it difficult to explain how the upper bit of version is set, but is not really a version change. But messing with gmt_unix_time might cause trouble since it's possible that _something_ out there might rely on it (for what I have no idea). So since the bottom few bytes of the random have no restriction whatsoever, putting the actual cipher suite there would not break anything. I'm not convinced that we need a field of flags, though, since we have TLS extensions. We should point out in our spec. that this solution is a HUGE compromise in the quest for backward compatibility, and that future fixes MAY require extensions. "You've been warned", etc. Mike Martin Rex wrote: > Actually we could use your idea for a more symmetric signaling! > > Stephen, I REALLY like this idea! > > > Since there are people that didn't like the gmt_unix_time > in Random anyway, we could just re-purpose it entirely. > > Add a single magic ciphersuite as first(!) in ClientHello.cipher_suites > and then the field "ClientRandom.gmt_unix_time" must be interpreted > > ClientHello.Random = > { > uint16 field_of_flags > uint16 reserved > opaque random_bytes[28] > } > > And when the server sees that magic cipher suite and implements > this protocol extension, then it will return the magic cipher suite > as negotiated ServerHello.cipher_suite and then the definition > of the ServerHello.Random will be this: > > ServerHello.Random = > { > uint16 field_of_flags > CipherSuite cipher_suite /* real negotiated cipher_suite */ > opaque random_bytes[28] > } > > Those implementors who want to keep a gmt_unix_time in their Random > to provide uniqueness, will need to put it somewhere into random_bytes, > like in the first 4 octets of that element. > > > This would give us 16 free bits for bi-directional signaling in > ClientHello and ServerHello at the cost of 2 Bytes in ClientHello. > > The fun part: these bit-flags are not only protected by the > handshake message hash, they actually go into the PRF for > the session keys. Some kind of extra protection. :) > > > -Martin > > PS: the session ID is used by servers to manage their cache > and may also be used by server-side load-balancers. > the session ID is only "random"-equivalent for the client From mrex@sap.com Fri Nov 20 12:16:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E523A6AA8 for ; Fri, 20 Nov 2009 12:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.161, 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 voayMOhYzkX1 for ; Fri, 20 Nov 2009 12:16:18 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E18713A6965 for ; Fri, 20 Nov 2009 12:16:17 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAKKGDLE007268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 21:16:13 +0100 (MET) From: Martin Rex Message-Id: <200911202016.nAKKGCmc023587@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 20 Nov 2009 21:16:12 +0100 (MET) In-Reply-To: <4B06F7ED.3000601@pobox.com> from "Michael D'Errico" at Nov 20, 9 12:11:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:16:19 -0000 Michael D'Errico wrote: > > I agree that something along these lines might be an improvement. > I found it difficult to explain how the upper bit of version is > set, but is not really a version change. > > But messing with gmt_unix_time might cause trouble since it's > possible that _something_ out there might rely on it (for what > I have no idea). So since the bottom few bytes of the random > have no restriction whatsoever, putting the actual cipher suite > there would not break anything. > > I'm not convinced that we need a field of flags, though, since > we have TLS extensions. We should point out in our spec. that > this solution is a HUGE compromise in the quest for backward > compatibility, and that future fixes MAY require extensions. > "You've been warned", etc. You're correct. gmt_unix_time was first in that position, --it should not have to move. The following should work just as well along with the magic ciphersuite that indicates this protocol change. ClientHello.Random = { uint32 gmt_unix_time; uint16 new_protocol_flag_bits; uint16 reserved; opaque random_bytes[24]; } ServerHello.Random = { uint32 gmt_unix_time; uint16 new_protocol_flag_bits; CipherSuite cipher_suite; opaque random_bytes[24]; } -Martin > > Martin Rex wrote: > > Actually we could use your idea for a more symmetric signaling! > > > > Stephen, I REALLY like this idea! > > > > > > Since there are people that didn't like the gmt_unix_time > > in Random anyway, we could just re-purpose it entirely. > > > > Add a single magic ciphersuite as first(!) in ClientHello.cipher_suites > > and then the field "ClientRandom.gmt_unix_time" must be interpreted > > > > ClientHello.Random = > > { > > uint16 field_of_flags > > uint16 reserved > > opaque random_bytes[28] > > } > > > > And when the server sees that magic cipher suite and implements > > this protocol extension, then it will return the magic cipher suite > > as negotiated ServerHello.cipher_suite and then the definition > > of the ServerHello.Random will be this: > > > > ServerHello.Random = > > { > > uint16 field_of_flags > > CipherSuite cipher_suite /* real negotiated cipher_suite */ > > opaque random_bytes[28] > > } > > > > Those implementors who want to keep a gmt_unix_time in their Random > > to provide uniqueness, will need to put it somewhere into random_bytes, > > like in the first 4 octets of that element. > > > > > > This would give us 16 free bits for bi-directional signaling in > > ClientHello and ServerHello at the cost of 2 Bytes in ClientHello. > > > > The fun part: these bit-flags are not only protected by the > > handshake message hash, they actually go into the PRF for > > the session keys. Some kind of extra protection. :) > > > > > > -Martin > > > > PS: the session ID is used by servers to manage their cache > > and may also be used by server-side load-balancers. > > the session ID is only "random"-equivalent for the client From ynir@checkpoint.com Fri Nov 20 12:17:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF793A6ACF for ; Fri, 20 Nov 2009 12:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 xWxTX-9P2t-k for ; Fri, 20 Nov 2009 12:17:54 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5B2763A6965 for ; Fri, 20 Nov 2009 12:17:54 -0800 (PST) X-CheckPoint: {4B06F5E7-1-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A3A8A29C005; Fri, 20 Nov 2009 22:17:47 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 78A3229C004; Fri, 20 Nov 2009 22:17:47 +0200 (IST) X-CheckPoint: {4B06F5E3-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAKKHkGo023916; Fri, 20 Nov 2009 22:17:47 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 20 Nov 2009 22:17:53 +0200 From: Yoav Nir To: "Michael D'Errico" Date: Fri, 20 Nov 2009 22:17:46 +0200 Thread-Topic: [TLS] Need for S->C signaling Thread-Index: AcpqHomVHVCmNJ1XTXey3Ygi5ZW1Jw== Message-ID: <1864CA31-BEF7-4FFB-A012-A0A15A6D5DFF@checkpoint.com> References: <200911201921.nAKJLfcs020068@fs4113.wdf.sap.corp> <4B06F7ED.3000601@pobox.com> In-Reply-To: <4B06F7ED.3000601@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org list" Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:17:55 -0000 On Nov 20, 2009, at 10:11 PM, Michael D'Errico wrote: > I agree that something along these lines might be an improvement. > I found it difficult to explain how the upper bit of version is > set, but is not really a version change. >=20 > But messing with gmt_unix_time might cause trouble since it's > possible that _something_ out there might rely on it (for what > I have no idea). How about: If the client has its clock set way into the future, you don't w= ant to send it a certificate that is already expired. That works even better the other way. If the client does have its clock set= to the past, you can send it an expired certificate. Peter Gutmann says that many implementations randomize this value for exact= ly that reason. That is an important data point, because since such implementations are out= there (and presumably working), it's safe to assume that we CAN mess with = this field. > So since the bottom few bytes of the random > have no restriction whatsoever, putting the actual cipher suite > there would not break anything. >=20 > I'm not convinced that we need a field of flags, though, since > we have TLS extensions. We should point out in our spec. that > this solution is a HUGE compromise in the quest for backward > compatibility, and that future fixes MAY require extensions. > "You've been warned", etc. >=20 > Mike >=20 From ynir@checkpoint.com Fri Nov 20 12:22:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9E33A67BD for ; Fri, 20 Nov 2009 12:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 fegLYAebUUER for ; Fri, 20 Nov 2009 12:22:04 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A8AEF3A6848 for ; Fri, 20 Nov 2009 12:22:03 -0800 (PST) X-CheckPoint: {4B06F6E0-4-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9E18029C005; Fri, 20 Nov 2009 22:22:00 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 82DAE29C004; Fri, 20 Nov 2009 22:22:00 +0200 (IST) X-CheckPoint: {4B06F6E0-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAKKLxGo024749; Fri, 20 Nov 2009 22:22:00 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 20 Nov 2009 22:22:06 +0200 From: Yoav Nir To: Marsh Ray Date: Fri, 20 Nov 2009 22:21:58 +0200 Thread-Topic: [TLS] Need for S->C signaling Thread-Index: AcpqHyB5KmtSQfH6QoGjUOby/fMQWA== Message-ID: References: <334EA87E-FDC3-4A45-B4EB-316A046EBFFD@checkpoint.com> <4B05C6D8.6030205@extendedsubset.com> In-Reply-To: <4B05C6D8.6030205@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:22:05 -0000 OK. So this is the case where the MitM has already sent the entire request,= and the server decided it wants client authentication, and there is no ses= sion cookie that needs to be sent. Although for nearly all HTTPS cases this won't work, I guess it could happe= n. =20 On Nov 20, 2009, at 12:29 AM, Marsh Ray wrote: > Yoav Nir wrote: >>=20 >> But even if the server did send the CCS and Finished message, the >> Finished message does not check out, >> so the client does not complete the request. So where's the damage. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > http://tools.ietf.org/html/rfc4346 > Client Server >=20 > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data >=20 > Fig. 1. Message flow for a full handshake >=20 >=20 > The client has to send his Finished message before he sees the server's. >=20 > The server executes the request when he receives Finished from the > client. There is nothing later he can wait for, really. >=20 > MitM can drop the server's Finished message before the client gets a > chance to verify it. >=20 > - Marsh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Scanned by Check Point Total Security Gateway. From jsalowey@cisco.com Fri Nov 20 13:53:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98303A6953 for ; Fri, 20 Nov 2009 13:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 SWR6m1ATp8xx for ; Fri, 20 Nov 2009 13:53:35 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 019583A67CC for ; Fri, 20 Nov 2009 13:53:34 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAOfBkurR7Ht/2dsb2JhbAC9KZdogjaCBgQ X-IronPort-AV: E=Sophos;i="4.47,260,1257120000"; d="scan'208";a="273498508" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 20 Nov 2009 21:53:28 +0000 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.14.3) with ESMTP id nAKLrSQ9016870 for ; Fri, 20 Nov 2009 21:53:28 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.3959); Fri, 20 Nov 2009 13:53:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Nov 2009 13:53:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: AcpqK+P+FJb7/ERHTaOcgXqgj6VcUg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 20 Nov 2009 21:53:28.0570 (UTC) FILETIME=[E4A5F5A0:01CA6A2B] Subject: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:53:35 -0000 We have had a lot of good discussion on this list, but I think we need to start converging on a solution. As I said in a previous message, I've asked Eric to serve as editor for the WG draft and he has posted draft-ietf-tls-renegotiation-00 as a starting point. I realize that there are a number of people who aren't happy with aspects of the draft, or indeed with the draft as a whole, but I'd like to get the sense for the feelings of the group as a whole. If we have rough consensus that this is a workable approach, we can try to nail down the remaining issues and move forward. To try to keep this concrete, please respond with answers to this question: Support for the draft: - I support this draft - I support this draft with the following modification - I would support an entirely different proposal (please identify it; be specific)=20 If you are proposing a modification, in addition to providing a description and rationale for a modification to the document it is helpful to provide sample text of the modification. Also, please indicate whether you would only support the draft with your modification or whether you can live with it unmodified. =20 Thanks, Joe From mrex@sap.com Fri Nov 20 13:54:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E1F28C154 for ; Fri, 20 Nov 2009 13:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.158, 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 hAbFGF01VdfM for ; Fri, 20 Nov 2009 13:54:44 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 3718228C11D for ; Fri, 20 Nov 2009 13:54:44 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAKLseR8028321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 22:54:40 +0100 (MET) From: Martin Rex Message-Id: <200911202154.nAKLsdeG029681@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 20 Nov 2009 22:54:39 +0100 (MET) In-Reply-To: <4B06F7ED.3000601@pobox.com> from "Michael D'Errico" at Nov 20, 9 12:11:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: [TLS] merging recent ideas into one new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:54:45 -0000 I was just on the phone with Nasko Oskov and he came up with another very interesting idea about how to get the verify data into the handshake message hash of the renegotiation. I like that idea even better than mine! So combined with Steve's idea to signal S->C through ServerHello.cipher_suite, this is the result: And this will fit into the SSL Version 2 ClientHello (which is still permitted by RFC-5246 Appendix E !). TLS/SSL ClientHello.Random maps to V2 ClientHello.challenge, they're both 32-bytes So the entire new scheme looks like this: We put the first 12 bytes of the verify_data of the finished messages into the Hello.Random of renegotiation handshakes. This will obviate the need to hash them manually, they will go into the handshake message hash through the respective Randoms. A new (single) magic ciphersuite ID, where the client requests to talk the updated protocol. This must be first in the ClientHello.cipher_suites. ClientHello.Random original new, initial HS new, renegotiation HS { uint32 gmt_unix_time uint32 gmt_unix_time uint32 gmt_unix_time opaque random[32] uint16 new_flags uint16 new_flags uint16 reserved uint16 reserved opaque random[12] opaque random[12] opaque random[12] opaque cli.verify_data[12] } = 32 bytes = 32 bytes = 32 bytes When an updated server sees the new magic ciphersuite ID, then it writes the magic cipher suite ID into ServerHello.cipher_suite in order to confirm to the client the use of the changed protocol and writes the real negotiated cipher suite ID into the new definition of the ServerHello.Random: ServerHello.Random original new, initial HS new, renegotiation HS uint32 gmt_unix_time uint32 gmt_unix_time uint32 gmt_unix_time opaque random[32] uint16 new_flags uint16 new_flags uint16 cipher_suite uint16 cipher_suite opaque random[12] opaque random[12] opaque random[12] opaque srv.verify_data[12] } = 32 bytes = 32 bytes = 32 bytes For those wondering whether it is a good idea or safeto actually cut into the Hello.Random that much? I'm not a cryptographer, but I think it is safe. The 2x 16 bit that I'm cutting with flags and relocated ciphersuite is admittedly a loss in randomness. But it should be bearable. What about the 12 bytes for the verify_data in the renegotiation handshake? That should actually _not_ have an impact! What are the necessary properties for Random, which serves as a challenge for both communication peers. - unique ? yes - non-predictable ? yes - secret ? no, it is sent in the clear For the authentication of the previous session in the renegotiation handshake, we actually assume for the verify_data of the finished messages the following attributes: - unique - non-predictable Of course, we should run this by cryptographers, but to me, it does _not_ fundamentally flawed, but OK. And what do I need that 16 bits of flags for? Well, I think they do come in handy to grow a little fruit. Those of the low hanging kind. :) Possible uses of that Bitfield: #define TLS_FLAG_SECURE_RENGOTIATE (1u<< 0) #define TLS_FLAG_RENEGOTIATE_SAME_IDENTITY (1u<< 1) #define TLS_FLAG_INITIAL_HANDSHAKE (1u<< 2) #define TLS_FLAG_WILL_NOT_RENEGOTIATE (1u<< 3) #define TLS_FLAG_HAVE_NO_CERT (1u<< 4) -Martin From mrex@sap.com Fri Nov 20 14:01:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608013A67CC for ; Fri, 20 Nov 2009 14:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.093 X-Spam-Level: X-Spam-Status: No, score=-6.093 tagged_above=-999 required=5 tests=[AWL=0.156, 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 cBk27ZPwBxge for ; Fri, 20 Nov 2009 14:01:19 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 13C743A672F for ; Fri, 20 Nov 2009 14:01:18 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAKM1Eeb022507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Nov 2009 23:01:15 +0100 (MET) From: Martin Rex Message-Id: <200911202201.nAKM1EFd000310@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Fri, 20 Nov 2009 23:01:14 +0100 (MET) In-Reply-To: <200911202154.nAKLsdeG029681@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 20, 9 10:54:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Subject: Re: [TLS] merging recent ideas into one new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:01:20 -0000 What I forgot about the verify_data in the Hello.Randoms: We only carry the initial 12 bytes -- which is the standard size for TLSv1.0 and TLSv1.1 and the default size for TLSv1.2. For SSLv3, where the Finished message is actually a concatenation of two HMAs md5 and sha1 (I believe it is an HMAC-like thingy) we would carry the first 12 bytes of the sha-1 HMAC as verify_data. -Martin From mike-list@pobox.com Fri Nov 20 14:05:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400873A67D3 for ; Fri, 20 Nov 2009 14:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 q7QMdFIWU8hB for ; Fri, 20 Nov 2009 14:05:28 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 29DA53A63D3 for ; Fri, 20 Nov 2009 14:05:27 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0F1459E92E for ; Fri, 20 Nov 2009 17:05:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=bM/ZV2M1oZyP LSpLmcoVs5UvK60=; b=fuhA5St16s7rAUxoW44uq7q5MMKC3tIbi8wCrPGSiasF jmQ6mP5v7pEROi64a45J8Af4M5VyOwjG8wuf6LyparIzwpvNDmw8I/hGV1lhxHW2 s010vq3A3z4XgvqDXnnuKUl81V8aP5w51LUnln4BhX1i6hTyHiGCKE4vfJQR2wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=s03pUA 5hP4QH1lpmNU+MldoqpvMfntXP+yj3BvaJMBV/aOGM/J0T06RyyuqHm3RMPMZTuU foq5SRN05+fgMBvGKBmTd1gTG/KhYRVfsW782vDmiQg2+tOWImszhHWDmmDqzLhF 7u8J5xazNVbBPgX2Z2ZTMnsWWLRl42sqvgKpc= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0C4F19E92D for ; Fri, 20 Nov 2009 17:05:25 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 9181A9E92C for ; Fri, 20 Nov 2009 17:05:24 -0500 (EST) Message-ID: <4B0712F9.6040102@pobox.com> Date: Fri, 20 Nov 2009 14:06:49 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911202154.nAKLsdeG029681@fs4113.wdf.sap.corp> In-Reply-To: <200911202154.nAKLsdeG029681@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CDEF3982-D620-11DE-86D3-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] merging recent ideas into one new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:05:29 -0000 It might be possible to truncate the verify_data to something less than all 12 bytes, similar to how we have the option to truncate the HMAC. Plus for SSLv3, the verify_data is 36 bytes! Also maybe only one byte of flags instead of 2. Mike Martin Rex wrote: > I was just on the phone with Nasko Oskov and he came up with another > very interesting idea about how to get the verify data into the > handshake message hash of the renegotiation. I like that idea > even better than mine! So combined with Steve's idea to > signal S->C through ServerHello.cipher_suite, this is the result: > > > And this will fit into the SSL Version 2 ClientHello > (which is still permitted by RFC-5246 Appendix E !). > TLS/SSL ClientHello.Random maps to V2 ClientHello.challenge, > they're both 32-bytes > > > So the entire new scheme looks like this: > > > We put the first 12 bytes of the verify_data of the finished > messages into the Hello.Random of renegotiation handshakes. > This will obviate the need to hash them manually, they will > go into the handshake message hash through the respective > Randoms. > > A new (single) magic ciphersuite ID, where the client requests > to talk the updated protocol. This must be first in the > ClientHello.cipher_suites. > > > ClientHello.Random > > original new, initial HS new, renegotiation HS > { > uint32 gmt_unix_time uint32 gmt_unix_time uint32 gmt_unix_time > opaque random[32] uint16 new_flags uint16 new_flags > uint16 reserved uint16 reserved > opaque random[12] opaque random[12] > opaque random[12] opaque cli.verify_data[12] > } > = 32 bytes = 32 bytes = 32 bytes > > When an updated server sees the new magic ciphersuite ID, then it > writes the magic cipher suite ID into ServerHello.cipher_suite > in order to confirm to the client the use of the changed protocol > and writes the real negotiated cipher suite ID into the new definition > of the ServerHello.Random: > > > ServerHello.Random > > original new, initial HS new, renegotiation HS > > uint32 gmt_unix_time uint32 gmt_unix_time uint32 gmt_unix_time > opaque random[32] uint16 new_flags uint16 new_flags > uint16 cipher_suite uint16 cipher_suite > opaque random[12] opaque random[12] > opaque random[12] opaque srv.verify_data[12] > } > = 32 bytes = 32 bytes = 32 bytes > > > For those wondering whether it is a good idea or safeto actually > cut into the Hello.Random that much? > > I'm not a cryptographer, but I think it is safe. > > The 2x 16 bit that I'm cutting with flags and relocated ciphersuite > is admittedly a loss in randomness. But it should be bearable. > > What about the 12 bytes for the verify_data in the renegotiation > handshake? That should actually _not_ have an impact! > > What are the necessary properties for Random, which serves as > a challenge for both communication peers. > > - unique ? yes > - non-predictable ? yes > - secret ? no, it is sent in the clear > > For the authentication of the previous session in the renegotiation > handshake, we actually assume for the verify_data of the finished > messages the following attributes: > > - unique > - non-predictable > > Of course, we should run this by cryptographers, but to me, it > does _not_ fundamentally flawed, but OK. > > > And what do I need that 16 bits of flags for? > > Well, I think they do come in handy to grow a little fruit. > Those of the low hanging kind. :) > > > Possible uses of that Bitfield: > > #define TLS_FLAG_SECURE_RENGOTIATE (1u<< 0) > #define TLS_FLAG_RENEGOTIATE_SAME_IDENTITY (1u<< 1) > #define TLS_FLAG_INITIAL_HANDSHAKE (1u<< 2) > #define TLS_FLAG_WILL_NOT_RENEGOTIATE (1u<< 3) > #define TLS_FLAG_HAVE_NO_CERT (1u<< 4) > > > > -Martin > From Nicolas.Williams@sun.com Fri Nov 20 14:22:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD3A3A6953 for ; Fri, 20 Nov 2009 14:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[AWL=0.531, 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 WkyiqtMnyAIf for ; Fri, 20 Nov 2009 14:22:28 -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 C45AD3A67D3 for ; Fri, 20 Nov 2009 14:22:28 -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 nAKMMQtf021005 for ; Fri, 20 Nov 2009 22:22:26 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 nAKMMPBe045571 for ; Fri, 20 Nov 2009 15:22:25 -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 nAKM3HKd003196; Fri, 20 Nov 2009 16:03:17 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAKM3Hax003195; Fri, 20 Nov 2009 16:03:17 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 20 Nov 2009 16:03:17 -0600 From: Nicolas Williams To: "Joseph Salowey (jsalowey)" Message-ID: <20091120220317.GG773@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:22:29 -0000 On Fri, Nov 20, 2009 at 01:53:27PM -0800, Joseph Salowey (jsalowey) wrote: > To try to keep this concrete, please respond with answers to this > question: > > Support for the draft: > - I support this draft > - I support this draft with the following modification > - I would support an entirely different proposal (please identify it; be > specific) I support this draft with only INFORMATIVE modifications about the fact that this is "like an RFC5056 channel binding facility used with tls-unique-for-telnet channel bindings data for the outer/previous TLS connection, but it is not a generic-purpose channel binding facility and may not be used for other channel binding types", plus an informative reference to RFC5056. I might support an entirely different proposal, but only if there's consensus for it amongst implementors, or if there's strong consensus that a different proposal is more likely to interoperate. I've to catch up with a week's worth of e-mail in order to determine which proposal, if any, and whether any strong arguments have been made about the [non-]interoperability of the RI proposal (but I suspect there have not been any). Nico -- From mrex@sap.com Fri Nov 20 14:31:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BA73A6884 for ; Fri, 20 Nov 2009 14:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.153, 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 LVRJu4ZhE9nl for ; Fri, 20 Nov 2009 14:31:26 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 03B333A67D3 for ; Fri, 20 Nov 2009 14:31:25 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAKMVJtm014290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 23:31:19 +0100 (MET) From: Martin Rex Message-Id: <200911202231.nAKMVJP6002208@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joseph Salowey) Date: Fri, 20 Nov 2009 23:31:19 +0100 (MET) In-Reply-To: from "Joseph Salowey" at Nov 20, 9 01:53:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:31:27 -0000 Joseph Salowey wrote: > > draft-ietf-tls-renegotiation-00 I support an entirely different proposal, described here: http://www.ietf.org/mail-archive/web/tls/current/msg04572.html and over the weekend I will incorporate this into the I-D that I'm working. I will try hard to ship the I-D on Monday 23-Nov-09. -Martin From stefan@aaa-sec.com Fri Nov 20 14:45:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED543A6828 for ; Fri, 20 Nov 2009 14:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csOAMj-NjFKN for ; Fri, 20 Nov 2009 14:45:11 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 143DE3A6805 for ; Fri, 20 Nov 2009 14:45:10 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E7A17291680 for ; Fri, 20 Nov 2009 23:45:14 +0100 (CET) Received: (qmail 24138 invoked from network); 20 Nov 2009 22:45:06 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Nov 2009 22:45:06 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 20 Nov 2009 23:45:05 +0100 From: Stefan Santesson To: , Michael D'Errico Message-ID: Thread-Topic: [TLS] merging recent ideas into one new proposal Thread-Index: AcpqMxpD1ByDza7XKUyxewY8wd57tA== In-Reply-To: <200911202154.nAKLsdeG029681@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] merging recent ideas into one new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:45:12 -0000 Martin, The repurposing of basic protocol elements smells too much like an ugly hack to me. It give me all kinds of bad vibes. I liked the old proposal better. /Stefan On 09-11-20 10:54 PM, "Martin Rex" wrote: > I was just on the phone with Nasko Oskov and he came up with another > very interesting idea about how to get the verify data into the > handshake message hash of the renegotiation. I like that idea > even better than mine! So combined with Steve's idea to > signal S->C through ServerHello.cipher_suite, this is the result: > > > And this will fit into the SSL Version 2 ClientHello > (which is still permitted by RFC-5246 Appendix E !). > TLS/SSL ClientHello.Random maps to V2 ClientHello.challenge, > they're both 32-bytes > > > So the entire new scheme looks like this: > > > We put the first 12 bytes of the verify_data of the finished > messages into the Hello.Random of renegotiation handshakes. > This will obviate the need to hash them manually, they will > go into the handshake message hash through the respective > Randoms. > > A new (single) magic ciphersuite ID, where the client requests > to talk the updated protocol. This must be first in the > ClientHello.cipher_suites. > > > ClientHello.Random > > original new, initial HS new, renegotiation HS > { > uint32 gmt_unix_time uint32 gmt_unix_time uint32 gmt_unix_time > opaque random[32] uint16 new_flags uint16 new_flags > uint16 reserved uint16 reserved > opaque random[12] opaque random[12] > opaque random[12] opaque cli.verify_data[12] > } > = 32 bytes = 32 bytes = 32 bytes > > When an updated server sees the new magic ciphersuite ID, then it > writes the magic cipher suite ID into ServerHello.cipher_suite > in order to confirm to the client the use of the changed protocol > and writes the real negotiated cipher suite ID into the new definition > of the ServerHello.Random: > > > ServerHello.Random > > original new, initial HS new, renegotiation HS > > uint32 gmt_unix_time uint32 gmt_unix_time uint32 gmt_unix_time > opaque random[32] uint16 new_flags uint16 new_flags > uint16 cipher_suite uint16 cipher_suite > opaque random[12] opaque random[12] > opaque random[12] opaque srv.verify_data[12] > } > = 32 bytes = 32 bytes = 32 bytes > > > For those wondering whether it is a good idea or safeto actually > cut into the Hello.Random that much? > > I'm not a cryptographer, but I think it is safe. > > The 2x 16 bit that I'm cutting with flags and relocated ciphersuite > is admittedly a loss in randomness. But it should be bearable. > > What about the 12 bytes for the verify_data in the renegotiation > handshake? That should actually _not_ have an impact! > > What are the necessary properties for Random, which serves as > a challenge for both communication peers. > > - unique ? yes > - non-predictable ? yes > - secret ? no, it is sent in the clear > > For the authentication of the previous session in the renegotiation > handshake, we actually assume for the verify_data of the finished > messages the following attributes: > > - unique > - non-predictable > > Of course, we should run this by cryptographers, but to me, it > does _not_ fundamentally flawed, but OK. > > > And what do I need that 16 bits of flags for? > > Well, I think they do come in handy to grow a little fruit. > Those of the low hanging kind. :) > > > Possible uses of that Bitfield: > > #define TLS_FLAG_SECURE_RENGOTIATE (1u<< 0) > #define TLS_FLAG_RENEGOTIATE_SAME_IDENTITY (1u<< 1) > #define TLS_FLAG_INITIAL_HANDSHAKE (1u<< 2) > #define TLS_FLAG_WILL_NOT_RENEGOTIATE (1u<< 3) > #define TLS_FLAG_HAVE_NO_CERT (1u<< 4) > > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From rrelyea@redhat.com Fri Nov 20 15:11:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32C63A67A1 for ; Fri, 20 Nov 2009 15:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 4Tlxj0cEv18J for ; Fri, 20 Nov 2009 15:11:36 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 422F928C10F for ; Fri, 20 Nov 2009 15:11:31 -0800 (PST) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAKNBQMw019663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Nov 2009 18:11:26 -0500 Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAKNBPes021569 for ; Fri, 20 Nov 2009 18:11:25 -0500 Message-ID: <4B07221C.8050808@REDHAT.COM> Date: Fri, 20 Nov 2009 15:11:24 -0800 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.97a Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070303090306090900080105" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 23:11:43 -0000 This is a cryptographically signed message in MIME format. --------------ms070303090306090900080105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/20/2009 01:53 PM, Joseph Salowey (jsalowey) wrote: > We have had a lot of good discussion on this list, but I think we need > to start converging on a solution. As I said in a previous message, I'v= e > asked Eric to serve as editor for the WG draft and he has posted > draft-ietf-tls-renegotiation-00 as a starting point. I realize that > there are a number of people who aren't happy with aspects of the draft= , > or indeed with the draft as a whole, but I'd like to get the sense for > the feelings of the group as a whole. If we have rough consensus that > this is a workable approach, we can try to nail down the remaining > issues and move forward. > > To try to keep this concrete, please respond with answers to this > question: > > Support for the draft: > - I support this draft > - I support this draft with the following modification > - I would support an entirely different proposal (please identify it; b= e > specific)=20 > =20 I support this draft. bob --------------ms070303090306090900080105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV7DCC Bv8wggXnoAMCAQICAwCrKTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MTAxNDAwMDAwMVoXDTEwMTAxNDIwNTQyMVowbjEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9dBmw8V94Rx84iwE5RpiO+uHKS5e91CHnKf JsbEOzPxS7Hgizt78ratBbhkudQ7bJIH1o9nh0Q5c/LdOlWUF1Jn+3+JNGvs6h/vlmfCYGPK TZpUbwPm8Rmik+bDNlAOUkDieZHfUg8HOdGrqvp1prqqwLMzgovi5YiETf28SO9kxNqjkbBL VxsBlHrnjG1dmn8jAYZ1XPctXMEsHV+2EISDOPYWl/CE2jt7km6Hkxq7D6p/z8Ef9Zn/uZ1z onthvoDp+BJOIIa6s68r9rLGNtAQ5/OtxXKpk6Cz5SAUgZIo0p2tNyQ2hFy8ojUZm2hNKVfu 6lN9DcSU0sri8I0S1QIDAQABo4IDhTCCA4EwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6fisKv/TEZ8c96u/L+x4d RtrwdjCBqAYDVR0jBIGgMIGdgBRTcu2SnODaywFcfH6WNU7y1LhRgqGBgaR/MH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eYIBDTAdBgNVHREEFjAUgRJycmVseWVhQHJlZGhhdC5jb20wggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNz bC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRk LjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8E XDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAOBrTD2DJvI0rP6phlUjV0JU6owP2XLQ2fZZ42J LHqfJ+yJWqpprzbHK7c7oJjy/TlNUQzFQZvtQM0WAcopsOzvqeXyB9lt6Zqq1ULMG9s5yMM0 rq/dpYFE2ju9WY8+7962iSkqGmMwrq9ZwO8J37zmMDS3ifw3/n3/Ns1t7MK6tanzkugScuW9 TQr/zQNNanLQmeuvU6Fbru6UFZI6c1qW0G4B1ptfTEQiAQ+E7PdIdjI9SYd24uU6/OdPlGrV tgl0UUnwLuCwA+D84xtc4+TjkLFxuqKCTi0NDONzosPzrNGJ7Kcau5bqV5AUxVz6bUifqQ3a X7xgD7Vq0EGCCK4wggb/MIIF56ADAgECAgMAqykwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0wOTEwMTQwMDAwMDFaFw0xMDEwMTQyMDU0 MjFaMG4xHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVk aGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfXQZsPFfeEcfOIsBOU aYjvrhykuXvdQh5ynybGxDsz8Uux4Is7e/K2rQW4ZLnUO2ySB9aPZ4dEOXPy3TpVlBdSZ/t/ iTRr7Oof75ZnwmBjyk2aVG8D5vEZopPmwzZQDlJA4nmR31IPBznRq6r6daa6qsCzM4KL4uWI hE39vEjvZMTao5GwS1cbAZR654xtXZp/IwGGdVz3LVzBLB1fthCEgzj2FpfwhNo7e5Juh5Ma uw+qf8/BH/WZ/7mdc6J7Yb6A6fgSTiCGurOvK/ayxjbQEOfzrcVyqZOgs+UgFIGSKNKdrTck NoRcvKI1GZtoTSlX7upTfQ3ElNLK4vCNEtUCAwEAAaOCA4UwggOBMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+n4r Cr/0xGfHPervy/seHUba8HYwgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKh gYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQu Y29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQW DVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEt Y3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADga0w9gybyNKz+qYZVI1d CVOqMD9ly0Nn2WeNiSx6nyfsiVqqaa82xyu3O6CY8v05TVEMxUGb7UDNFgHKKbDs76nl8gfZ bemaqtVCzBvbOcjDNK6v3aWBRNo7vVmPPu/etokpKhpjMK6vWcDvCd+85jA0t4n8N/59/zbN bezCurWp85LoEnLlvU0K/80DTWpy0Jnrr1OhW67ulBWSOnNaltBuAdabX0xEIgEPhOz3SHYy PUmHduLlOvznT5Rq1bYJdFFJ8C7gsAPg/OMbXOPk45Cxcbqigk4tDQzjc6LD86zRieynGruW 6leQFMVc+m1In6kN2l+8YA+1atBBggiuMIIH4jCCBcqgAwIBAgIBDTANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGB pH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkw VzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w b2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0 ZXMwDQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP /4H/Bc8FFDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhp cqMr3OyzK3aYGJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyR WTTX6mWSv+TraOwuj3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNh HeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG8 59MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6Gu UcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf 6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIO uAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdC taW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/TyxV/stlehMYID0DCC A8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMAkGBSsO AwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5 MTEyMDIzMTEyNFowIwYJKoZIhvcNAQkEMRYEFBpTyFwyBYs5369cJBWmidHONBhlMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBAIhq2AcvuD6V5gmdd4HE6ZuA4boUraj3YtTzB/a9y9zlyVdhRDND IDYIP4ikXk1PW7Xtwk3dg6/7zOAJerCEMgV5rzpIzhKU1/bpGTv0AjTDSeK1fm1lfqoCARe6 yDHoPhvRMwPtavet6EvnRD/eYUafu9JeZm8X0GtWsGMyi6goO/AHuHTatWnEDHcOKuTyUBvD ES/4icLJuq8DZYBbRWWmBFhPBs+I+JXoNGl8HqiOt9Pj37vJR/uIPz13XqX5+0j8ypogiW+7 sLpD4jevrUv2O2B1IDj2rnSaMFBOumEDgmd5Ao8iH0s8HextYl1Ou1l6eJGVtAtGaxrbciKf 5t0AAAAAAAA= --------------ms070303090306090900080105-- From stefan@aaa-sec.com Fri Nov 20 15:14:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3023A63D3 for ; Fri, 20 Nov 2009 15:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trt8RdiTetsw for ; Fri, 20 Nov 2009 15:14:03 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id F1C453A672F for ; Fri, 20 Nov 2009 15:14:02 -0800 (PST) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 9FD5628E0B4 for ; Sat, 21 Nov 2009 00:12:17 +0100 (CET) Received: (qmail 16300 invoked from network); 20 Nov 2009 23:12:08 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Nov 2009 23:12:08 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sat, 21 Nov 2009 00:12:07 +0100 From: Stefan Santesson To: "Joseph Salowey (jsalowey)" , Message-ID: Thread-Topic: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: AcpqK+P+FJb7/ERHTaOcgXqgj6VcUgACv0Ow In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 23:14:04 -0000 I would support an entirely different proposal that supports SSLv3 -> TLS 1.2 using a common approach, I.e. Not using TLS extensions. The condition is that the implementer community can agree on such approach within a reasonable timeframe. In absence of such agreement, I would support this draft. /Stefan On 09-11-20 10:53 PM, "Joseph Salowey (jsalowey)" wrote: > We have had a lot of good discussion on this list, but I think we need > to start converging on a solution. As I said in a previous message, I've > asked Eric to serve as editor for the WG draft and he has posted > draft-ietf-tls-renegotiation-00 as a starting point. I realize that > there are a number of people who aren't happy with aspects of the draft, > or indeed with the draft as a whole, but I'd like to get the sense for > the feelings of the group as a whole. If we have rough consensus that > this is a workable approach, we can try to nail down the remaining > issues and move forward. > > To try to keep this concrete, please respond with answers to this > question: > > Support for the draft: > - I support this draft > - I support this draft with the following modification > - I would support an entirely different proposal (please identify it; be > specific) > > If you are proposing a modification, in addition to providing a > description and rationale for a modification to the document it is > helpful to provide sample text of the modification. Also, please > indicate whether you would only support the draft with your modification > or whether you can live with it unmodified. > > Thanks, > > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Chris.Newman@Sun.COM Fri Nov 20 15:24:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE5B3A672F for ; Fri, 20 Nov 2009 15:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 1k0q2XqXFthD for ; Fri, 20 Nov 2009 15:24:15 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 1594A3A635F for ; Fri, 20 Nov 2009 15:24:15 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAKNOCQc005293 for ; Fri, 20 Nov 2009 15:24:12 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTF00J00KRBE000@fe-sfbay-09.sun.com> for tls@ietf.org; Fri, 20 Nov 2009 15:24:12 -0800 (PST) Received: from vpn-129-150-240-239.sfbay.sun.com ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTF00IA1L091JE0@fe-sfbay-09.sun.com>; Fri, 20 Nov 2009 15:24:12 -0800 (PST) Date: Fri, 20 Nov 2009 15:24:09 -0800 From: Chris Newman In-reply-to: <200911192123.nAJLNh8E014666@fs4113.wdf.sap.corp> Sender: Chris.Newman@Sun.COM To: mrex@sap.com, David-Sarah Hopwood Message-id: <72F218683F2638BF41208A6D@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <200911192123.nAJLNh8E014666@fs4113.wdf.sap.corp> Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 23:24:16 -0000 --On November 19, 2009 22:23:43 +0100 Martin Rex wrote: > Asking SSLv3 implementations to improve on their extensions-intolerance > is still OK. Requiring them to implement generic TLS extensions > is not, because it has nothing to do with the problem and is > an unnecessary complexity for the fix. What if we require SSLv3 compatible clientHello and SSLv3 serverHello to list RI first and at least ignore additional extensions, waiving the requirement for full extension support for SSLv3-only implementations? The we'd have only one way to advertise that the client/server is patched to fix the renegotiation vulnerability, but we reduce the amount of work necessary to fix an SSLv3-only implementation (to the point where it provides the level of security and renegotiate functionality that SSLv3 claimed to provide)? - Chris From mrex@sap.com Fri Nov 20 16:02:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452D63A67E4 for ; Fri, 20 Nov 2009 16:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ii4LIM-Yuzhq for ; Fri, 20 Nov 2009 16:02:18 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 302963A67BE for ; Fri, 20 Nov 2009 16:02:17 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAL02DbP005978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Nov 2009 01:02:13 +0100 (MET) From: Martin Rex Message-Id: <200911210002.nAL02CEx007574@fs4113.wdf.sap.corp> To: Chris.Newman@Sun.COM (Chris Newman) Date: Sat, 21 Nov 2009 01:02:12 +0100 (MET) In-Reply-To: <72F218683F2638BF41208A6D@446E7922C82D299DB29D899F> from "Chris Newman" at Nov 20, 9 03:24:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:02:19 -0000 Chris Newman wrote: > > --On November 19, 2009 22:23:43 +0100 Martin Rex wrote: > > Asking SSLv3 implementations to improve on their extensions-intolerance > > is still OK. Requiring them to implement generic TLS extensions > > is not, because it has nothing to do with the problem and is > > an unnecessary complexity for the fix. > > What if we require SSLv3 compatible clientHello and SSLv3 serverHello to > list RI first and at least ignore additional extensions, waiving the > requirement for full extension support for SSLv3-only implementations? I don't see how this would solve the problem. How to you interoperate with installed base SSLv3 and TLSv1.0 that is extensions-intolerant without being vulnerable to downgrade attacks? The restriction that this extension must be first comes very unnatural and is bound to result in interop problems, because it will usually not show up in tests that have generic TLS extension functionality. It seems like dangerous design. Maybe this explains the abstract problem better: If you look at the two different possibilities to get the verify_data into the handshake message hash on renegotiation: 1) put them into a handshake message and they will be hashed automatically 2) have each peer add them manually to the handshake message hash directly after ServerHello which of the two is better engineering-wise? Definitely (2). (1) is incomplete and fails unsafe. It is unlikely that if (2) was used that _everyone_ would implement it incorrectly. If implemented incorrectly, you will get interop problems when testing with regular old and new peers. So this approach fails safe. No matter how poorly you implement (1), you will always interoperate. What is missing in (1) is the requirement, that the verify_data in the handshake messages is actually verified by the receiver! If you have implementors that actually forget to perform the comparison, you will NEVER notice this in interop-tests. You will actually need to build yourself attack-tools to make sure that your implementations actually verify that data. So approach (2) fails UNsafe. It is true that I did add (2) to my last proposal by including the verify_data in the Hello.Random elements. *I* still prefer to call the hash function manually, because it will fail safe. -Martin From mike-list@pobox.com Fri Nov 20 16:05:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283323A67BE for ; Fri, 20 Nov 2009 16:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 t7dvSKvG9YdN for ; Fri, 20 Nov 2009 16:05:30 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 3C7F93A67B2 for ; Fri, 20 Nov 2009 16:05:30 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 22D03819EA for ; Fri, 20 Nov 2009 19:05:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=0gwXHSAsC2v2 +RNdb03N92Vk4Ok=; b=SBOH3+YE52KhztZxHTYfYQSMYdwOQR5hmePzAOuxtuWg Ylt18tlNTZyu4gI6+GkQ1utIxY8DPMjLPb6VmYIySnI4jQnYuE1XYNBZMVWRlknW ab3GOe2mpAA0LPxaskDJumBDWm4jNDaC+RBpyoxSZvV+9hF8+KLFpLq5uAgm8Is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=FMlejA ktc6RZG66xuaCVmflDUks+KWe8QAmqwRKxD2vOkq4O0ueNSN1XwpXalHzb7llFzI yCQdrTzDvADi1iTrhe6LIJOiAz8qHUDjTKUhNWz8G0bJRTzvLzeVC/27o8oojrdJ 0jmHN2ZWKjXHNrDH0BjbA262idCaDz0kwyhGM= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1EFD3819E9 for ; Fri, 20 Nov 2009 19:05:27 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C9800819E8 for ; Fri, 20 Nov 2009 19:05:26 -0500 (EST) Message-ID: <4B072F1C.8050505@pobox.com> Date: Fri, 20 Nov 2009 16:06:52 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 92B7AC12-D631-11DE-B0A1-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] Another critical problem with RI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:05:31 -0000 Here is yet another reason to reject Renegotiation_Info: The security of RI relies on implementations verifying that the data carried in the extension is correct. It is possible for implementors to get this wrong. A client or server could correctly get all of the mechanics of sending and receiving the extension working but fail to actually compare what they received to the old verify_data. Looking at the bits-on-the-wire it will not be possible to tell that a client or server is broken in this way. These broken implementations will be able to perform initial connections and renegotiations. Such a broken client paired with a broken server would still be vulnerable to a MitM attack. Changing the Finished message calculation, on the other hand, is fool- proof. Either you add the old verify_data to the handshake messages or you don't. If you don't, then handshakes will fail regularly[*] and the problem will be noticed and fixed. Note that adding the verify_data to the ClientHello.random and ServerHello.random suffers from this same problem. Mike [*] To make this even more fool-proof, I suggest making sure that the data added to the handshake message stream is never empty (i.e. as it would be on an initial handshake in Martin's proposal); this can be easily done by including length byte(s) or even a single fixed byte. From mike-list@pobox.com Fri Nov 20 16:07:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA0A3A6824 for ; Fri, 20 Nov 2009 16:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 aWEnYpzre-eP for ; Fri, 20 Nov 2009 16:07:47 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 9C9683A6808 for ; Fri, 20 Nov 2009 16:07:47 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 088A581A33 for ; Fri, 20 Nov 2009 19:07:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=RiQ8xqIycslX V74H6hhZBznGqHQ=; b=Q34iBGb0LZSzoYGTKSJea+bi1Z4cxtwRxvuBgiTRrSiB 44FdMqoqiHsZrXRTAIRbVxoCd8Pt4O6Qr6ojJn+bOzDfgoXiRyYYGqE7jRhpZ+ja 0QYKPLsL/Q2pOtZmYMEyj5wUMI99WBBjDpSrQqYFPRJIJEYNyUr7Z9gPxlr8HB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=TErZ1n BM2b9fOUjRL09q64oYuBI/i/nsKbeROOcyHVW+/tB9VQ3/7F4sKDUNuyDh7mU285 XMxlAtrrd/zmfSB7XwHQ/VZ3sXV9Qo49pR3hg2WcUDgDAZ2XIahZKMxCZjRgUFoL M9IqgKaqiPMZZ2B+Qqa+dFPAI1UbFGGeIhogA= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0588881A32 for ; Fri, 20 Nov 2009 19:07:44 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id B27E081A31 for ; Fri, 20 Nov 2009 19:07:44 -0500 (EST) Message-ID: <4B072FA6.9050205@pobox.com> Date: Fri, 20 Nov 2009 16:09:10 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B072F1C.8050505@pobox.com> In-Reply-To: <4B072F1C.8050505@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E4E88F60-D631-11DE-B0A1-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Another critical problem with RI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:07:48 -0000 It looks like I got scooped by Martin by 4 minutes! :-) Mike Michael D'Errico wrote: > Here is yet another reason to reject Renegotiation_Info: > > The security of RI relies on implementations verifying that the data > carried in the extension is correct. It is possible for implementors > to get this wrong. A client or server could correctly get all of the > mechanics of sending and receiving the extension working but fail to > actually compare what they received to the old verify_data. Looking > at the bits-on-the-wire it will not be possible to tell that a client > or server is broken in this way. These broken implementations will > be able to perform initial connections and renegotiations. Such a > broken client paired with a broken server would still be vulnerable > to a MitM attack. > > Changing the Finished message calculation, on the other hand, is fool- > proof. Either you add the old verify_data to the handshake messages > or you don't. If you don't, then handshakes will fail regularly[*] > and the problem will be noticed and fixed. > > Note that adding the verify_data to the ClientHello.random and > ServerHello.random suffers from this same problem. > > Mike > > [*] To make this even more fool-proof, I suggest making sure that the > data added to the handshake message stream is never empty (i.e. as it > would be on an initial handshake in Martin's proposal); this can be > easily done by including length byte(s) or even a single fixed byte. From rdugal@certicom.com Fri Nov 20 16:11:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D753A67BE for ; Fri, 20 Nov 2009 16:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 d7c8R6xudFGC for ; Fri, 20 Nov 2009 16:11:44 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 2E7813A6808 for ; Fri, 20 Nov 2009 16:11:44 -0800 (PST) X-AuditID: 0a666446-b7b5eae0000003bc-b3-4b07303cd9d8 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 93.F0.00956.C30370B4; Fri, 20 Nov 2009 19:11:40 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 19:11:40 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Fri, 20 Nov 2009 19:11:39 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402699F3E@XCH57YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: AcpqK+P+FJb7/ERHTaOcgXqgj6VcUgAEzyqA References: From: "Robert Dugal" To: X-OriginalArrivalTime: 21 Nov 2009 00:11:40.0112 (UTC) FILETIME=[32CADD00:01CA6A3F] X-Brightmail-Tracker: AAAAAwAAAZERyCBQEctxlg== Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:11:46 -0000 I support this draft -- Robert Dugal Senior Software Developer Certicom Corp. A Subsidiary of Research In Motion rdugal@certicom.com direct=A0=A0=A0=A0=A0=A0=A0=A0905.501.3848 fax=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0905.507.4230 www.certicom.com -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Joseph= Salowey (jsalowey) Sent: Friday, November 20, 2009 4:53 PM To: tls@ietf.org Subject: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt We have had a lot of good discussion on this list, but I think we need to start converging on a solution. As I said in a previous message, I've asked Eric to serve as editor for the WG draft and he has posted draft-ietf-tls-renegotiation-00 as a starting point. I realize that there are a number of people who aren't happy with aspects of the draft, or indeed with the draft as a whole, but I'd like to get the sense for the feelings of the group as a whole. If we have rough consensus that this is a workable approach, we can try to nail down the remaining issues and move forward. To try to keep this concrete, please respond with answers to this question: Support for the draft: - I support this draft - I support this draft with the following modification - I would support an entirely different proposal (please identify it; be specific) If you are proposing a modification, in addition to providing a description and rationale for a modification to the document it is helpful to provide sample text of the modification. Also, please indicate whether you would only support the draft with your modification or whether you can live with it unmodified. Thanks, Joe _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From wtc@google.com Fri Nov 20 17:02:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27193A6808 for ; Fri, 20 Nov 2009 17:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 oFkldTZgG5zK for ; Fri, 20 Nov 2009 17:02:05 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 262C33A67D7 for ; Fri, 20 Nov 2009 17:02:05 -0800 (PST) Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id nAL120T2028515 for ; Fri, 20 Nov 2009 17:02:01 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258765322; bh=8Z9lY3mMejwr5yopFJl5Aa+8qKY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TdipokyHRmBJ3OMJZqh0VDOOlItzea+cpuNSCjQz7p8lEpmwfRl57UBlo6GEJRmR7 SGj3GvBy+hAmaP+GPubIA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=BOS2+eBCjymM0Pkw0pJpM0EcrhwJmz7FUEeF1C8I0ghtwCrXVb534Y2+C1p3u/bN0 lf1rE62WUAG52OPTv15XA== Received: from pwi17 (pwi17.prod.google.com [10.241.219.17]) by spaceape23.eur.corp.google.com with ESMTP id nAL11vq1002196 for ; Fri, 20 Nov 2009 17:01:58 -0800 Received: by pwi17 with SMTP id 17so2672828pwi.19 for ; Fri, 20 Nov 2009 17:01:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.248.5 with SMTP id v5mr224708wfh.272.1258765317103; Fri, 20 Nov 2009 17:01:57 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Nov 2009 17:01:57 -0800 Message-ID: From: Wan-Teh Chang To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 01:02:06 -0000 I support using EKR's draft for TLS and an ugly, dirty hack like those proposed by Michael D'Errico, Martin Rex, and Nasko Oskov for SSL 3.0. Wan-Teh Chang From wtc@google.com Fri Nov 20 17:07:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855183A68D9 for ; Fri, 20 Nov 2009 17:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 MBnH3Llhf5Um for ; Fri, 20 Nov 2009 17:07:58 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id DA71D3A683D for ; Fri, 20 Nov 2009 17:07:57 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id nAL17r3a001060 for ; Fri, 20 Nov 2009 17:07:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258765674; bh=H4PGxhyedBWU5pw5t3xe8cGO4X4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=FZ85pOOTloO8nXhXv+xiYHnky70al4cXsMjFUP8ZCQOvtaKaeOae5A1ISwjXLEXHK BvRj4FgayYkjVRJOh3Ang== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=QTvGffaV6QLSxVQ0et3fpDgLiXpDtEqG0ANik+HjYgXxvvPRid21Hd1vp1QJAXHnw zQV9QSw0sEFnB7pRFdOyg== Received: from pzk38 (pzk38.prod.google.com [10.243.19.166]) by wpaz37.hot.corp.google.com with ESMTP id nAL17odU028560 for ; Fri, 20 Nov 2009 17:07:51 -0800 Received: by pzk38 with SMTP id 38so2830255pzk.9 for ; Fri, 20 Nov 2009 17:07:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.3.35 with SMTP id 35mr221642wfc.84.1258765670504; Fri, 20 Nov 2009 17:07:50 -0800 (PST) In-Reply-To: References: <200911202154.nAKLsdeG029681@fs4113.wdf.sap.corp> Date: Fri, 20 Nov 2009 17:07:50 -0800 Message-ID: From: Wan-Teh Chang To: Stefan Santesson Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] merging recent ideas into one new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 01:07:59 -0000 On Fri, Nov 20, 2009 at 2:45 PM, Stefan Santesson wrote: > Martin, > > The repurposing of basic protocol elements smells too much like an ugly hack > to me. It give me all kinds of bad vibes. > > I liked the old proposal better. Martin, I agree. I like your old proposal better (adding a magic cipher suite in client hello, turning on a bit in server_version in server hello). Wan-Teh Chang From mrex@sap.com Fri Nov 20 17:09:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4053A68DB for ; Fri, 20 Nov 2009 17:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.148, 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 xpxSp2i+TkrQ for ; Fri, 20 Nov 2009 17:09:03 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3FA1A3A683D for ; Fri, 20 Nov 2009 17:09:03 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAL18v8T005754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Nov 2009 02:08:57 +0100 (MET) From: Martin Rex Message-Id: <200911210108.nAL18vh7011493@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Sat, 21 Nov 2009 02:08:57 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Nov 20, 9 11:45:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] merging recent ideas into one new proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 01:09:04 -0000 Stefan, Stefan Santesson wrote: > > The repurposing of basic protocol elements smells too much like > an ugly hack to me. It give me all kinds of bad vibes. > > I liked the old proposal better. Thanks for the feedback. When I just started to describe the architecture of storing the verify_data of the previous Finished message in the Hello.Random, I realized that interop-testing this would not provide any proof that an implementation was no longer vulnerable, i.e. it's a fail UNsafe design just like TLS extension RI. So I'm going to complete the I-D with the last design, based on "manually" adding the verify_data to the handshake hashes and S->C signaling through server_version. -Martin PS: I still like Steve's idea, though. It would be fairly symmetric in signaling: the Client offers a magic cipher suite for a modified protocol first in his list of cipher_suites and the server agrees to use it and sends it back in ServerHello.cipher_suite. With the same symmetry, 32-bit of Hello.Random are re-purposed. The negotiation through the ciphersuite would make this re-purposing of the Hello.Random bits non-ambiguous and one could add 16 bidirectional signaling bits of extensibility for use by TLS WG. If the information that you want to negotiate with your peer amounts to essentially one bit, then a TLS extension is a pretty big wrapping. What would you say if your super-market would sell 1 quart of milk only in a box of lead that weighs 80lbs ? From mrex@sap.com Fri Nov 20 17:33:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF453A68E1 for ; Fri, 20 Nov 2009 17:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=0.145, 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 jms5xtAZCP3R for ; Fri, 20 Nov 2009 17:33:34 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 961223A67D7 for ; Fri, 20 Nov 2009 17:33:34 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAL1XU4L018925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Nov 2009 02:33:30 +0100 (MET) From: Martin Rex Message-Id: <200911210133.nAL1XTJE013102@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Sat, 21 Nov 2009 02:33:29 +0100 (MET) In-Reply-To: <4B072FA6.9050205@pobox.com> from "Michael D'Errico" at Nov 20, 9 04:09:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Another critical problem with RI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 01:33:35 -0000 Michael D'Errico wrote: > > Michael D'Errico wrote: > > Here is yet another reason to reject Renegotiation_Info: > > It looks like I got scooped by Martin by 4 minutes! :-) I'm sorry. It seems that you thought about what it would mean to implement my newest idea (tunneling verify_data into the handshake message hash through Hello.Random, somewhat similar to what TLS extension RI does) and realized this problem. I had just started to change my I-D that I'm working on and describe the new idea when I stumbled over this problem. It was somewhat similar when I was trying to explain to Nico and Larry that they can not simply ignore that channel bindings don't carry over through TLS renegotiation, when I realized that TLS renegotiation would therefore be susceptible to MitM attacks. -Martin From mrex@sap.com Fri Nov 20 19:02:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55353A67F6 for ; Fri, 20 Nov 2009 19:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.143, 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 j0cqwqLqW3-U for ; Fri, 20 Nov 2009 19:02:10 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 942453A67A7 for ; Fri, 20 Nov 2009 19:02:10 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAL31cI3011611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Nov 2009 04:01:38 +0100 (MET) From: Martin Rex Message-Id: <200911210301.nAL31bMO018402@fs4113.wdf.sap.corp> To: jsalowey@cisco.com Date: Sat, 21 Nov 2009 04:01:37 +0100 (MET) In-Reply-To: <200911202231.nAKMVJP6002208@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 20, 9 11:31:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 03:02:11 -0000 Martin Rex wrote: > > Joseph Salowey wrote: > > > > draft-ietf-tls-renegotiation-00 > > I support an entirely different proposal, described here: > > http://www.ietf.org/mail-archive/web/tls/current/msg04572.html > > and over the weekend I will incorporate this into the I-D that > I'm working. I will try hard to ship the I-D on Monday 23-Nov-09. While trying to document the new idea I realized that embedding the previous finished messages into real handshake messages leads to a fail UNsafe design just like TLS extenion RI. So I will stick to what I've been working on through the week and what Mike has already implemented (manually add verify_data to the handshake message hash without sending it over the network, C->S signaling by magic ciphersuite and S->C signaling with higest bit of ServerHello.server_version.major. I-D on monday. -Martin From noskov@microsoft.com Fri Nov 20 19:17:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7CA3A68EE for ; Fri, 20 Nov 2009 19:17:33 -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 W2pst+ZcAnsF for ; Fri, 20 Nov 2009 19:17:32 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9B1603A68BF for ; Fri, 20 Nov 2009 19:17:32 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Nov 2009 19:17:51 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.21; Fri, 20 Nov 2009 19:17:28 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 20 Nov 2009 19:17:27 -0800 From: Nasko Oskov To: "Joseph Salowey (jsalowey)" , "tls@ietf.org" Thread-Topic: Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: AcpqK+P+FJb7/ERHTaOcgXqgj6VcUgALFpcw Date: Sat, 21 Nov 2009 03:15:38 +0000 Deferred-Delivery: Sat, 21 Nov 2009 03:16:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: A9yI BupJ Fq/n GCek IS+O I87N Jnuz KHey K4iu MM5Z McyV NxmB OXDO OnpG O6EY RiIK; 2; agBzAGEAbABvAHcAZQB5AEAAYwBpAHMAYwBvAC4AYwBvAG0AOwB0AGwAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {33FB5AB4-5A27-4DF9-89FE-C34CDDA20F65}; bgBvAHMAawBvAHYAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Sat, 21 Nov 2009 03:16:00 GMT; UgBFADoAIABDAG8AbgBzAGUAbgBzAHUAcwAgAEMAYQBsAGwAIABmAG8AcgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQB0AGwAcwAtAHIAZQBuAGUAZwBvAHQAaQBhAHQAaQBvAG4ALQAwADAALgB0AHgAdAA= x-cr-puzzleid: {33FB5AB4-5A27-4DF9-89FE-C34CDDA20F65} Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 03:17:33 -0000 I support the TLS extension approach for TLS1.0 and above with the modifica= tion that we add the magic cipher suite in the client hello. This will allo= w a TLS ClientHello with the extension to be used against SSLv3 only server= (assuming server properly ignores extensions). For SSLv3 I support Martin Rex's proposal of cipher suite client to server = and version bit in server to client. Nasko From djhopwood@googlemail.com Fri Nov 20 20:10:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E437D3A681C for ; Fri, 20 Nov 2009 20:10:19 -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 Q+YKP4cNU4Io for ; Fri, 20 Nov 2009 20:10:15 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id EF2BA3A68A3 for ; Fri, 20 Nov 2009 20:10:14 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so1075514eya.51 for ; Fri, 20 Nov 2009 20:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=W7uIYhNBV3YrgZWxRsHihsYQFpQnc+6Vji+NASL+jp4=; b=f00ZIlQxwnc0ru5g9ka0EtPMkWhUC2C80GKiVgn9cKV3J1kwRUCn5/OEvCqNF8u/wP c0jmOSxUcghFLu8XjsLeffH1zvx/ihhTUz57E4yL6WK5NgAUyo1SYysSbGOldEvaN3Yk diT2DRPsUhSYNnDDaaETOcHUG1+Kntu+RqhPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=WhkQ0z4aG97q0wszSuThIFmYOkLO/H/es/3EgrcqLRm1DZlBvk3Okn3gC/fQUw2q7S BHOsBDyymymNYAWh+NCWrJ5+eCqr/H0W9mdzX2F5bfRNO91Akyb29M5g8hYOnqXRlpAw dwWSkxDoQr2bWkdOU0fRE7gniJstJvuxcrC4A= Received: by 10.213.2.84 with SMTP id 20mr2160110ebi.46.1258776607732; Fri, 20 Nov 2009 20:10:07 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm583747ewy.0.2009.11.20.20.10.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Nov 2009 20:10:06 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B07673D.3070204@jacaranda.org> Date: Sat, 21 Nov 2009 04:06:21 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911201828.nAKISN6Y017007@fs4113.wdf.sap.corp> In-Reply-To: <200911201828.nAKISN6Y017007@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB0B19C857D6C50FF91EFC8D5" Subject: Re: [TLS] RC4+3DES rekeying - long-lived TLS connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 04:10:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB0B19C857D6C50FF91EFC8D5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Peter Saint-Andre wrote: >> ... For example in XMPP >> we use long-lived TCP connections and, on top of those, long-lived XML= >> streams that can be TLS-protected. In practice, for server-to-server >> federation (and even for client-to-server communication) those >> connections might be up for days, weeks, even months. At this point th= e >> handling of long-lived XML streams is unspecified, but I would expect >> most XMPP servers to terminate the connection and force the other part= y >> to reconnect. >=20 > There was a discussion around long-lived SSL connections and > reasons for rekeying, e.g. using TLS renegotiation on mogul-open. >=20 > If you're using ciphersuites with RC4 or 3DES encryption algorithms, > you probably should not use such connections for prolonged times > or huge amounts of data without rekeying (see below). As far as I know, RC4 as used in TLS does not have a significant problem with encrypting large amounts of data. There are small statistical biases in the RC4 keystream but they're not a serious threat in most situations. If you're worried about the information leakage in using 3DES for long-lived connections, then it's probably a better option to disable 3DES ciphersuites, than to use renegotiation to rekey. I think that disabling 3DES should not cause significant interoperability problems provided you continue to offer both RC4 and AES ciphersuites. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB0B19C857D6C50FF91EFC8D5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksHZ/AACgkQWUc8YzyzqAfZ7AD/UmhOe9CVgkV1RbQwz4dSlIbI Fhmi0iKg04Ji4TmpsccA/0lPDMBGNV4j+J9ibsJMTQLa/5bv1a17VJAtOpq9tz04 =wMAs -----END PGP SIGNATURE----- --------------enigB0B19C857D6C50FF91EFC8D5-- From djhopwood@googlemail.com Fri Nov 20 20:33:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCE53A67B0 for ; Fri, 20 Nov 2009 20:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdfoPW7wC5Mr for ; Fri, 20 Nov 2009 20:33:57 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 6A8C53A676A for ; Fri, 20 Nov 2009 20:33:57 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so1078822eya.51 for ; Fri, 20 Nov 2009 20:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=XE6potbrYfT7Y9ou3WU4NhFbR3WlKO+kt17O8i1Dwhw=; b=Y3tR9debLpnkTJXz+lC/ErfkVWw+zGD81P7sl7ApEMvtfn6C2wFh0rDVAdicLUVuBH G4c9J2VwLx7KbGGUUEPTxPSdnG16cadj0eLm39W03DwTDd+HxKGZHyVPAxWgqWMuE22K TLDCPpeT02c8Sq0Vdt9tx4Sn0jzTjpLZOqGb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=ejJZQZSZkIcGic3pfRwhiGVNx+Zv9ZxK3UrCQ9TvQ9ZD1BXn5Liq4uVbgeQHi7w0hD kENJoncIICKpS5sI8DRGpCxxH2SooxZYufw2CHunXpVzULRJhrQik3CN4jqHjxuPnChe 1aFOTAGdplNmeVv/KbWdNKtcaCBhwjFcwx/hs= Received: by 10.213.23.213 with SMTP id s21mr962629ebb.76.1258778031659; Fri, 20 Nov 2009 20:33:51 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 7sm528613eyg.25.2009.11.20.20.33.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Nov 2009 20:33:50 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B076D70.4080809@jacaranda.org> Date: Sat, 21 Nov 2009 04:32:48 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig929DEA25BE0B0BC32262BDC6" Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 04:33:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig929DEA25BE0B0BC32262BDC6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nasko Oskov wrote: > I support the TLS extension approach for TLS1.0 and above with the > modification that we add the magic cipher suite in the client hello. > This will allow a TLS ClientHello with the extension to be used > against SSLv3 only server (assuming server properly ignores extensions)= =2E The RI approach can be used with an extension-tolerant SSLv3-only server even without the "magic ciphersuite". --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig929DEA25BE0B0BC32262BDC6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksHbXkACgkQWUc8YzyzqAfBDQD+OrvOPfsVkBNO/BF+nUv/RPP5 pijwlw/DTl8XlIDVZq0A/1hCx+hKCEqyREyDfmU2+KRxiQOdeFKKNRkGElp2E6Bg =9kVJ -----END PGP SIGNATURE----- --------------enig929DEA25BE0B0BC32262BDC6-- From mrex@sap.com Fri Nov 20 21:24:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C303C3A6783 for ; Fri, 20 Nov 2009 21:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.141, 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 eAdvfxJowSOP for ; Fri, 20 Nov 2009 21:24:07 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id C39F73A67E4 for ; Fri, 20 Nov 2009 21:24:06 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAL5O2Bt028926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Nov 2009 06:24:02 +0100 (MET) From: Martin Rex Message-Id: <200911210524.nAL5O1XY026844@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Sat, 21 Nov 2009 06:24:01 +0100 (MET) In-Reply-To: <4B076D70.4080809@jacaranda.org> from "David-Sarah Hopwood" at Nov 21, 9 04:32:48 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 05:24:07 -0000 David-Sarah Hopwood wrote: > > Nasko Oskov wrote: > > I support the TLS extension approach for TLS1.0 and above with the > > modification that we add the magic cipher suite in the client hello. > > This will allow a TLS ClientHello with the extension to be used > > against SSLv3 only server (assuming server properly ignores extensions). > > The RI approach can be used with an extension-tolerant SSLv3-only server > even without the "magic ciphersuite". The RI-approach will not completely prevent connectivity with an SSLv3-only but extension-tolerant server. It can, however, _not_ provide any protection either. In order to get secure renegotiation with an SSLv3-only server using TLS extension RI, that SSLv3-only server will have to add generic TLS extension support. And when that SSLv3-only server does not implement renegotiation, it will still need to add generic TLS extensions support in order to assure an updated client using TLS extension RI that it means no harm. -Martin From mike-list@pobox.com Fri Nov 20 21:58:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CBF3A67B3 for ; Fri, 20 Nov 2009 21:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 CfF+x4xTUHly for ; Fri, 20 Nov 2009 21:58:34 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id B592E3A67A5 for ; Fri, 20 Nov 2009 21:58:33 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 6D6C6A0561 for ; Sat, 21 Nov 2009 00:58:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=YUxY6DYS+spy Ct7PSEV3IExDZn8=; b=EBNROv3UnqhhWhSqFB/XHRBPKLIhv9T73CmCV7aHQKpH nUM8HLC8qF70GeQqFuhU55uV1Ri4lBR0iqIi8J3j7BTcj0SD82v39YGOHNfquyMM IJ1h4lEAvgZ5arAochyBb/9J6LI4AEVVJsuuVqlFm3/QhZ89niAf1nbLq+UnCdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=VCF6rN Yc4vPYsWvzk2aisyBH+nITamLu0CJyN1HcHM3J51FSsn1BkCi/fGMgbXX9/ILxzc qXnANW0ZXsCG+WiIP6Oq2e+ujFePRukWF/0txkJy72ybykbiwlQQ95IHLm92TgMb TEzHAQjo5E4dKOSpdA1/+jazq9oEhlvFYtNAA= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 6A2F3A0560 for ; Sat, 21 Nov 2009 00:58:30 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id F207FA055F for ; Sat, 21 Nov 2009 00:58:26 -0500 (EST) Message-ID: <4B0781D9.9070102@pobox.com> Date: Fri, 20 Nov 2009 21:59:53 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E4F1EC3C-D662-11DE-ADD0-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 05:58:35 -0000 I support a different approach, which I documented in this message: http://www.ietf.org/mail-archive/web/tls/current/msg04556.html It is the same as what Martin plans to issue an an Internet-Draft. I would be fine with modifying it slightly at the suggestion of Dr. Stephen Henson to have the server return the "magic" cipher suite in the ClientHello and to put the real cipher suite in the random. This would avoid difficulties in trying to explain how the version is modified, but not really modified. I'm just as upset about needing such a hack as everyone else, but the installed base has largely ignored extensions, so we can't responsibly force them on everyone. Plus, see how the RI extension is critically flawed anyway: http://www.ietf.org/mail-archive/web/tls/current/msg04582.html Mike Joseph Salowey (jsalowey) wrote: > We have had a lot of good discussion on this list, but I think we need > to start converging on a solution. As I said in a previous message, I've > asked Eric to serve as editor for the WG draft and he has posted > draft-ietf-tls-renegotiation-00 as a starting point. I realize that > there are a number of people who aren't happy with aspects of the draft, > or indeed with the draft as a whole, but I'd like to get the sense for > the feelings of the group as a whole. If we have rough consensus that > this is a workable approach, we can try to nail down the remaining > issues and move forward. > > To try to keep this concrete, please respond with answers to this > question: > > Support for the draft: > - I support this draft > - I support this draft with the following modification > - I would support an entirely different proposal (please identify it; be > specific) > > If you are proposing a modification, in addition to providing a > description and rationale for a modification to the document it is > helpful to provide sample text of the modification. Also, please > indicate whether you would only support the draft with your modification > or whether you can live with it unmodified. > > Thanks, > > Joe From stefan@aaa-sec.com Sat Nov 21 00:28:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DAE3A6851 for ; Sat, 21 Nov 2009 00:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rkgJJQXDrk0 for ; Sat, 21 Nov 2009 00:28:21 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id CC74B3A689B for ; Sat, 21 Nov 2009 00:28:19 -0800 (PST) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 175C6289D4B for ; Sat, 21 Nov 2009 09:28:18 +0100 (CET) Received: (qmail 2244 invoked from network); 21 Nov 2009 08:28:15 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Nov 2009 08:28:15 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sat, 21 Nov 2009 09:28:14 +0100 From: Stefan Santesson To: David-Sarah Hopwood , Message-ID: Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpqhJFVGhG8+/MaDUKIzLedcJ5JLA== In-Reply-To: <4B06E2D7.2040302@jacaranda.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 08:28:21 -0000 On 09-11-20 7:41 PM, "David-Sarah Hopwood" wrote: >> One example is if authentication is performed with proper channel binding in >> a layer above TLS and the service is provided under that security context. > > I'm skeptical. How can "proper channel binding" be done correctly in a > layer above TLS, if the TLS library merges renegotiated sessions? > Since the session merging will result in the client and server's state > at the higher layer(s) being out of sync, nothing can be assumed about > the correct functioning of those layers. The problem occurs on the clients initial handshake, being done in the clear, while the MITM is feeding this into a renegotiation with the server. As this attack has been described, once the client and server has concluded an end-to-end handshake, the window for the attacker to do bad stuff is closed. All renegotiations are safe from this point on. The very act of channel binding, binds authentication of the client to unique properties of the TLS channel. Thus, successful channel binding ensures that the client has concluded its first handshake (or it would not have anything to bind to). It also ensures that the TLS channel is carried end-to-end (or else channel binding would fail). So according to the logic above, successful channel binding would prove that the window for the attacker to do bad stuff is gone. /Stefan From lists@drh-consultancy.demon.co.uk Sat Nov 21 05:24:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB403A6870 for ; Sat, 21 Nov 2009 05:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 myBRJfxlcye2 for ; Sat, 21 Nov 2009 05:24:55 -0800 (PST) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by core3.amsl.com (Postfix) with ESMTP id A873B3A6359 for ; Sat, 21 Nov 2009 05:24:55 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49555 helo=[192.168.7.8]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10587) with esmtpa (authdaemon_plain:drh) id 1NBpxK-0005is-DE (Exim 4.69) for tls@ietf.org (return-path ); Sat, 21 Nov 2009 13:24:50 +0000 Message-ID: <4B07EA2B.5040809@drh-consultancy.demon.co.uk> Date: Sat, 21 Nov 2009 13:24:59 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> <4B059658.2010200@extendedsubset.com> In-Reply-To: <4B059658.2010200@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 13:24:57 -0000 Marsh Ray wrote: > Dr Stephen Henson wrote: >> What browsers and many libraries (including OpenSSL) do in the first place is to >> send an initial "version discovery" SSLv3 compatible client hello (or even >> SSLv2) with the version number set to the maximum number of SSL/TLS supported. >> The reply then indicates the version of SSL/TLS supported. Until that point you >> don't know what the server supports. So the connection can end up talking TLS >> v1.2 even though it initially sent and SSLv3 compatible client hello. > > So using extensions (even when both ends support TLS 1.1) would > significantly change the client hello for many current clients? Yngve of > Opera and Nelson of Mozilla had posted some connection logic that didn't > work quite like that. But now that you mention it that is what I see > from typical non-browser clients. > Just to add a point to this which hasn't really been mentioned. The discussion of connection logic has largely been browser centric, non-browser clients often work in a different way and the current proposal (draft-ietf-tls-renegotiation-01.txt) can cause them significant problems. As mentioned above an SSLv3 or even SSLv2 compatible client hello is commonly used to determine the servers capabilities and have maximum chance of success. Talking of "fallbacks" is all very well for browsers or libraries that have total control over the connection and can reconnect easily. That is not always the case. Libraries often get passed a file descriptor only. That may or may not be a connected socket: the transport doesn't have to be over TCP/IP. The library has to negotiate over that descriptor as best as it can. If the connection is dropped it's game over: the library cannot automatically reconnect in general. Reconnection can be done at the application level but if you have hundreds or thousands of applications, some not even maintained any more that is a daunting task (yes I'm talking about OpenSSL here). Updating a library in a way that is transparent to as many applications as possible is far easier. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From stephen.farrell@cs.tcd.ie Sat Nov 21 08:00:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F73F3A6801 for ; Sat, 21 Nov 2009 08:00:55 -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 0vnk-fUN1tkS for ; Sat, 21 Nov 2009 08:00:54 -0800 (PST) Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by core3.amsl.com (Postfix) with ESMTP id 4EDED3A695B for ; Sat, 21 Nov 2009 08:00:53 -0800 (PST) Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 84C5332FD3; Sat, 21 Nov 2009 16:00:49 +0000 (GMT) Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id nALG0dgk011035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 21 Nov 2009 16:00:45 GMT Message-ID: <4B080E9A.5030302@cs.tcd.ie> Date: Sat, 21 Nov 2009 16:00:26 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0009 (Score 0) X-Canit-Stats-ID: 57201606 - 12e78ff9c4e8 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 16:00:55 -0000 Joseph Salowey (jsalowey) wrote: > Support for the draft: > - I support this draft > - I support this draft with the following modification > - I would support an entirely different proposal (please identify it; be > specific) I support this draft for fixing TLS. If another draft emerges in a timely fashion that better addresses SSL then I might support that as well (either as a separate document or incorporated into this one). So far I can't tell if an SSL solution is worthwhile - despite all the words on the list, there's no I-D. S. From mike-list@pobox.com Sat Nov 21 08:06:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B347F3A680C for ; Sat, 21 Nov 2009 08:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 LXnOSgH+ced1 for ; Sat, 21 Nov 2009 08:06:42 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 2D40C3A6917 for ; Sat, 21 Nov 2009 08:06:42 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A7360814D8 for ; Sat, 21 Nov 2009 11:06:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rIDYyFqtvCTk K6Gy1WamSWodhm8=; b=uptYvkdjKnr93lHp/pjGQi1Lb5pPGfevzyShbuqPBZav Hdl3eC1gQasyEl2ZOSnKkTOsjCwJHdOsK8/mpG8NahaoFferDTSS7sT7HbhC27Dh tOAlD7d7mH4fI1YC2oHMYx+yQYQleKJ1aYGHeOj1hrNgGONjWWqPDXrB8l0Ep1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=iJ6Ubj uEYLQPzR9fU2yVSE4o/UdYh/S2q4GgxXAowg4h2yP9bn3uaGhMyR1BDXSEkC+obn eXY8ANQ5IQGJONKf0MoIwmEiVmaEA4BnU0rYuzQsawlomzyBPnP2XXmRuWZ4DqFb 0Hq2R8nhuE5a9EPAuGGqTYopxBGeWX+AKfPBY= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A301A814C7 for ; Sat, 21 Nov 2009 11:06:37 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 5A35B814C4 for ; Sat, 21 Nov 2009 11:06:37 -0500 (EST) Message-ID: <4B081066.4040903@pobox.com> Date: Sat, 21 Nov 2009 08:08:06 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> <4B059658.2010200@extendedsubset.com> <4B07EA2B.5040809@drh-consultancy.demon.co.uk> In-Reply-To: <4B07EA2B.5040809@drh-consultancy.demon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D90A6AA2-D6B7-11DE-8FBF-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 16:06:43 -0000 Dr Stephen Henson wrote: > > Talking of "fallbacks" is all very well for browsers or libraries that have > total control over the connection and can reconnect easily. That is not always > the case. Libraries often get passed a file descriptor only. That may or may not > be a connected socket: the transport doesn't have to be over TCP/IP. The library > has to negotiate over that descriptor as best as it can. If the connection is > dropped it's game over: the library cannot automatically reconnect in general. > > Reconnection can be done at the application level but if you have hundreds or > thousands of applications, some not even maintained any more that is a daunting > task (yes I'm talking about OpenSSL here). Updating a library in a way that is > transparent to as many applications as possible is far easier. I've been meaning to bring this up too. My TLS library knows nothing of sockets or even file descriptors. It is just a string processor. Above that is my socket library, and conceivable I could create a different class that communicates over a serial line or other connection type. If a solution requires reconnecting, then I can not limit the changes to just my TLS code. My socket code would need to change too. And most likely applications using the socket library would also need to be changed. This is unacceptable when there is a solution available that does not require these extensive modifications. Mike From fweimer@bfk.de Sat Nov 21 08:10:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EEE93A695B for ; Sat, 21 Nov 2009 08:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1MRxHPz4aDy for ; Sat, 21 Nov 2009 08:10:26 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id C5EC73A6917 for ; Sat, 21 Nov 2009 08:10:25 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1NBsXU-0005xw-6S; Sat, 21 Nov 2009 17:10:20 +0100 Received: by bfk.de with local id 1NBsXU-00018m-7f; Sat, 21 Nov 2009 16:10:20 +0000 To: "Joseph Salowey \(jsalowey\)" References: From: Florian Weimer Date: Sat, 21 Nov 2009 16:10:20 +0000 In-Reply-To: (Joseph Salowey's message of "Fri\, 20 Nov 2009 13\:53\:27 -0800") Message-ID: <82y6lzoo43.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 16:10:27 -0000 * Joseph Salowey: > - I support this draft I support this draft. The feature in section 4.4.1 should be included, but my support does not depend on that. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mike-list@pobox.com Sat Nov 21 08:47:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D1F3A692F for ; Sat, 21 Nov 2009 08:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 Xf2w3+UeZWUP for ; Sat, 21 Nov 2009 08:47:51 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 5DB163A6922 for ; Sat, 21 Nov 2009 08:47:50 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B1207817B2 for ; Sat, 21 Nov 2009 11:47:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=0+8iiwrDpXwN o81xVRVLd1R0eV0=; b=jVs2yK5nIcPZSCxNvEKud2QWA1s3T7UjIcjghq9q0RCc M0fgy6jeHY8zTiLsqnA13rYzeD2IAFafWeEAmhXKPnMob8P8ZgCFKFzTQ6vqJ/uW tuH7Rmd/pYFqvWFNORgyhqUckL83e0Z+CbZbhLEukQlXEsACybCSowk7ApwuHQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Z2geTV BWW5yVmqayqcroQ6o936wYA1i0Ici0sLC1OWCAd9fjH0TSUH1+YiNKQ5D2a+WvyJ lMGAKQHr99ED0QnF8XFrBT7qjkDIi0JTNO+hWfnqPvsl8k1q20F9gzAYTUbR2qsB t/mWPk3mw7Opc9+AUtXUx4BlxTpXT+W70NnVw= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id AD7B6817B1 for ; Sat, 21 Nov 2009 11:47:45 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 5B57D817B0 for ; Sat, 21 Nov 2009 11:47:44 -0500 (EST) Message-ID: <4B081A08.8010600@pobox.com> Date: Sat, 21 Nov 2009 08:49:12 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 981BBB58-D6BD-11DE-B3BD-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 16:47:52 -0000 Since the tide is going in the direction of this draft, I suggest the following change to make it fail-safe rather than have the flaw I pointed out in this message: http://www.ietf.org/mail-archive/web/tls/current/msg04582.html The change I propose is simple: - the extension is sent on every handshake and is always empty - the previous verify_data is added to the Finished calculation but not sent over the wire The latter should be done in the way that we want moving forward to future versions of TLS. I have implemented it by putting it in the handshake message stream immediately following the ServerHello; if that is undesirable long-term, please suggest an improvement. Mike Joseph Salowey (jsalowey) wrote: > We have had a lot of good discussion on this list, but I think we need > to start converging on a solution. As I said in a previous message, I've > asked Eric to serve as editor for the WG draft and he has posted > draft-ietf-tls-renegotiation-00 as a starting point. I realize that > there are a number of people who aren't happy with aspects of the draft, > or indeed with the draft as a whole, but I'd like to get the sense for > the feelings of the group as a whole. If we have rough consensus that > this is a workable approach, we can try to nail down the remaining > issues and move forward. > > To try to keep this concrete, please respond with answers to this > question: > > Support for the draft: > - I support this draft > - I support this draft with the following modification > - I would support an entirely different proposal (please identify it; be > specific) > > If you are proposing a modification, in addition to providing a > description and rationale for a modification to the document it is > helpful to provide sample text of the modification. Also, please > indicate whether you would only support the draft with your modification > or whether you can live with it unmodified. > > Thanks, > > Joe From lists@drh-consultancy.demon.co.uk Sat Nov 21 10:01:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11EA33A6A13 for ; Sat, 21 Nov 2009 10:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 30HdM42eH98Q for ; Sat, 21 Nov 2009 10:01:40 -0800 (PST) Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by core3.amsl.com (Postfix) with ESMTP id 32CEE3A689E for ; Sat, 21 Nov 2009 10:01:39 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49191 helo=[192.168.7.8]) by relay06.mail.eu.clara.net (relay.clara.net [213.253.3.46]:10587) with esmtpa (authdaemon_plain:drh) id 1NBuH8-00045c-Lj (Exim 4.69) for tls@ietf.org (return-path ); Sat, 21 Nov 2009 18:01:35 +0000 Message-ID: <4B082B08.3020406@drh-consultancy.demon.co.uk> Date: Sat, 21 Nov 2009 18:01:44 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 18:01:42 -0000 Joseph Salowey (jsalowey) wrote: > We have had a lot of good discussion on this list, but I think we need > to start converging on a solution. As I said in a previous message, I've > asked Eric to serve as editor for the WG draft and he has posted > draft-ietf-tls-renegotiation-00 as a starting point. I realize that > there are a number of people who aren't happy with aspects of the draft, > or indeed with the draft as a whole, but I'd like to get the sense for > the feelings of the group as a whole. If we have rough consensus that > this is a workable approach, we can try to nail down the remaining > issues and move forward. > > To try to keep this concrete, please respond with answers to this > question: > > Support for the draft: > - I support this draft > - I support this draft with the following modification > - I would support an entirely different proposal (please identify it; be > specific) > > If you are proposing a modification, in addition to providing a > description and rationale for a modification to the document it is > helpful to provide sample text of the modification. Also, please > indicate whether you would only support the draft with your modification > or whether you can live with it unmodified. > Firstly does this mean the 00 draft or the 01 one? I've mentioned elsewhere the fact that neither addresses SSLv2 or SSLv3 compatible client hellos (which may well end up talking TLS but they don't know that initially) and talk of fallbacks doesn't address APIs or libraries that cannot transparently reconnect. I'm not really concerned how this is addressed. I would support the 01 draft with the following modifications: 1. The magic ciphersuite as well as being used as a fallback can be used on initial connections if the client wishes to send an SSLv2 or SSLv3 compatible client hello or a TLS one without extensions. 2. Any server which accepts an SSLv2 or SSLv3 compatible client hello MUST be able to recognise the magic ciphersuite. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From djhopwood@googlemail.com Sat Nov 21 11:02:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037F13A6921 for ; Sat, 21 Nov 2009 11:02:16 -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 ibv427ZFqKT2 for ; Sat, 21 Nov 2009 11:02:15 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 85D583A69FF for ; Sat, 21 Nov 2009 11:02:14 -0800 (PST) Received: by ewy6 with SMTP id 6so633906ewy.29 for ; Sat, 21 Nov 2009 11:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=dmJxuT+VZwoHoI3iM6b+mOlAOjFWXzItvY6YQDOLZPA=; b=TKkXNpC5ewYQQGUYxeEBSrs3HgY/+2Zv1MdJuKLVrd6qzdl9r3w7xWvTyfYIOHAh1U XTnJ9CrR4Ig8Ty5bDnegD+bHrCCjKdqWCnBYihNoklnHA8HXdeSUaf3wzQMKu2NivhCh omweSiAVP4/ggQWZstu5SFPKjemoIIQQnHnD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=YuNjKhva/9UBwpaS3UnOY8g6UtUZiCrhcCO7hT0BCXn0wp4sK/gFg2uPxxxFWXGEwi Eln59kqosUoyCCebAKLthKJHDb+wTvy1AB+WWGm5YMna12JvnVt0wwYIJTgLLf70O5sN M0QYP6fW5oTM8wDvSASSEM0xwygUYWMRDj2as= Received: by 10.213.23.156 with SMTP id r28mr2772850ebb.86.1258830125229; Sat, 21 Nov 2009 11:02:05 -0800 (PST) Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 24sm661097eyx.6.2009.11.21.11.02.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 11:02:03 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0838E4.6010003@jacaranda.org> Date: Sat, 21 Nov 2009 19:00:52 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig08B2444EA144B5C6149AE5DC" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 19:02:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig08B2444EA144B5C6149AE5DC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stefan Santesson wrote: > On 09-11-20 7:41 PM, "David-Sarah Hopwood" > wrote: >=20 >>> One example is if authentication is performed with proper channel bin= ding in >>> a layer above TLS and the service is provided under that security con= text. >> >> I'm skeptical. How can "proper channel binding" be done correctly in a= >> layer above TLS, if the TLS library merges renegotiated sessions? >> Since the session merging will result in the client and server's state= >> at the higher layer(s) being out of sync, nothing can be assumed about= >> the correct functioning of those layers. >=20 > The problem occurs on the clients initial handshake, being done in the > clear, while the MITM is feeding this into a renegotiation with the ser= ver. >=20 > As this attack has been described, once the client and server has concl= uded > an end-to-end handshake, the window for the attacker to do bad stuff is= > closed. All renegotiations are safe from this point on. That's an oversimplification. The attacker is able to add a prefix to the server's view of the session.= This changes the server's state from what it would have been on an initial connection. How far the attacker's influence on the server's state extends into that session, is dependent on the application protocol= =2E > The very act of channel binding, binds authentication of the client to > unique properties of the TLS channel. Thus, successful channel binding= > ensures that the client has concluded its first handshake (or it would = not > have anything to bind to). It also ensures that the TLS channel is carr= ied > end-to-end (or else channel binding would fail). This is assuming away the problem. I said: # How can "proper channel binding" be done correctly in a layer above # TLS, if the TLS library merges renegotiated sessions? The attack has already disrupted the functioning of the layer above TLS. If any channel binding is done *at that layer* (or above), without knowledge of the TLS renegotiation boundaries and taking specific account= of the vulnerability in TLS, then it can't be assumed to be reliable. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig08B2444EA144B5C6149AE5DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksIOSAACgkQWUc8YzyzqAdJoQD+IaKKKrURjj2hZQLT34vONAGW 6aO8s9oT/fWd7lF/5AABAJwAqdeixHfAp1RHuTuGPDbsIKrm/h0luUnfFYvolNeP =K85Y -----END PGP SIGNATURE----- --------------enig08B2444EA144B5C6149AE5DC-- From benl@google.com Sat Nov 21 11:47:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D612D3A68D5 for ; Sat, 21 Nov 2009 11:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 udlGhYsgt2H3 for ; Sat, 21 Nov 2009 11:47:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 8DB823A68D1 for ; Sat, 21 Nov 2009 11:47:43 -0800 (PST) Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id nALJldbO019821 for ; Sat, 21 Nov 2009 19:47:39 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258832859; bh=KWo1WATBnMMZZQ2Wqwal0bozIdo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=yTUoVueYT+C6bQ6rlvhsYdbcipldRVJnpPnRGDd5vWmxQJW3FMNe/KPWMmi6UHwts 14a4ZkLK1ClisvPBBIb1Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=fqdQiBdgH/trnZwkrl34ilG1+4KzenIBcOQj7CrOpn4UKtKsfIyxWXHBEtvdmiIMN xSupBTUWux7Z6QARH9Qmw== Received: from qw-out-1920.google.com (qwc5.prod.google.com [10.241.193.133]) by spaceape14.eur.corp.google.com with ESMTP id nALJladR013347 for ; Sat, 21 Nov 2009 11:47:36 -0800 Received: by qw-out-1920.google.com with SMTP id 5so887956qwc.46 for ; Sat, 21 Nov 2009 11:47:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.52.38 with SMTP id f38mr387200qcg.26.1258832855993; Sat, 21 Nov 2009 11:47:35 -0800 (PST) In-Reply-To: <4B06E2D7.2040302@jacaranda.org> References: <4B06E2D7.2040302@jacaranda.org> Date: Sat, 21 Nov 2009 11:47:35 -0800 Message-ID: <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> From: Ben Laurie To: David-Sarah Hopwood Content-Type: multipart/alternative; boundary=0016e64bd3e6368c780478e6dd4b X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 19:47:44 -0000 --0016e64bd3e6368c780478e6dd4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood < david-sarah@jacaranda.org> wrote: > Stefan Santesson wrote: > > On 09-11-20 5:24 AM, "Michael D'Errico" wrote: > > > >> Some servers apparently cannot function without renegotiation. > >> They will need to continue providing service to unpatched > >> clients for some amount of time and thus remain vulnerable. > > > > I fully agree, > > > > However, just because a server accepts renegotiation with an unpatched > > client, does not necessarily mean that the service provided over TLS is > > vulnerable. > > > > One example is if authentication is performed with proper channel bindi= ng > in > > a layer above TLS and the service is provided under that security > context. > > I'm skeptical. How can "proper channel binding" be done correctly in a > layer above TLS, if the TLS library merges renegotiated sessions? > Since the session merging will result in the client and server's state > at the higher layer(s) being out of sync, nothing can be assumed about > the correct functioning of those layers. > The depends on those layers. If, for example, clients and servers simply numbered their requests/responses, they would be immune to the attack. > > > I second that lenient server - unpatched client must work while ensurin= g > > that lenient server - lenient client can't be abused using downgrade > > attacks. > > Obviously *if* lenient servers are supported, then we need to make sure > that lenient patched server - lenient patched client connections are > secure. But I remain unconvinced that lenient servers need to be supporte= d. > > -- > David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --0016e64bd3e6368c780478e6dd4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 20, 2009 at 10:41 AM, David-= Sarah Hopwood <david-sarah@jacaranda.org> wrote:
Stefan Santesson wrote:
> On 09-11-20 5:24 AM, "Michael D'Errico" <mike-list@pobox.com> wrote:
>
>> Some servers apparently cannot function wi= thout renegotiation.
>> They will need to continue providing service to unpatched
>> clients for some amount of time and thus remain vulnerable.
>
> I fully agree,
>
> However, just because a server accepts renegotiation with an unpatched=
> client, does not necessarily mean that the service provided over TLS i= s
> vulnerable.
>
> One example is if authentication is performed with proper channel bind= ing in
> a layer above TLS and the service is provided under that security cont= ext.

I'm skeptical. How can "proper channel binding" be done= correctly in a
layer above TLS, if the TLS library merges renegotiated sessions?
Since the session merging will result in the client and server's state<= br> at the higher layer(s) being out of sync, nothing can be assumed about
the correct functioning of those layers.

The depen= ds on those layers. If, for example, clients and servers simply numbered th= eir requests/responses, they would be immune to the attack.
=C2=A0

> I second that lenient server - unpatched client must work while ensuri= ng
> that lenient server - lenient client can't be abused using downgra= de
> attacks.

Obviously *if* lenient servers are supported, then we need to make su= re
that lenient patched server - lenient patched client connections are
secure. But I remain unconvinced that lenient servers need to be supported.=

--
David-Sarah Hopwood =C2=A0=E2=9A=A5 =C2=A0http://davidsarah.livejournal.com


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--0016e64bd3e6368c780478e6dd4b-- From benl@google.com Sat Nov 21 11:53:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650B73A6813 for ; Sat, 21 Nov 2009 11:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 zIy-L8Kntqrp for ; Sat, 21 Nov 2009 11:53:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id B536F3A67C0 for ; Sat, 21 Nov 2009 11:53:02 -0800 (PST) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id nALJqvOn011856 for ; Sat, 21 Nov 2009 19:52:58 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258833178; bh=mdopNWI23RPUe7Q95jvI5Pb7G0k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=nq/99bHDVcH+j4HTBtTgCxiDnPO6psdakXW8KzMmAXhcmb0OyPrOx1VgZDGudWzkm mp7COVlSrAjKMDyUG+T4w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=gm8hQiaKD4r4tyM0Sdcl9GxfmubR8F24ew9ud1oQf8ZhBYbv22fFzevKpe7t/UFZD pv2GFS/sQtJWfX3JuMtWA== Received: from qw-out-2122.google.com (qwd5.prod.google.com [10.241.193.197]) by zps19.corp.google.com with ESMTP id nALJqspN012391 for ; Sat, 21 Nov 2009 11:52:55 -0800 Received: by qw-out-2122.google.com with SMTP id 5so900889qwd.41 for ; Sat, 21 Nov 2009 11:52:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.9.83 with SMTP id k19mr403044qck.47.1258833174452; Sat, 21 Nov 2009 11:52:54 -0800 (PST) In-Reply-To: <4B082B08.3020406@drh-consultancy.demon.co.uk> References: <4B082B08.3020406@drh-consultancy.demon.co.uk> Date: Sat, 21 Nov 2009 11:52:54 -0800 Message-ID: <1b587cab0911211152s410265f8kf29ef73911c4a183@mail.gmail.com> From: Ben Laurie To: Dr Stephen Henson Content-Type: multipart/alternative; boundary=0016e64f44f031dbd20478e6f075 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 19:53:04 -0000 --0016e64f44f031dbd20478e6f075 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 21, 2009 at 10:01 AM, Dr Stephen Henson < lists@drh-consultancy.demon.co.uk> wrote: > Joseph Salowey (jsalowey) wrote: > > We have had a lot of good discussion on this list, but I think we need > > to start converging on a solution. As I said in a previous message, I've > > asked Eric to serve as editor for the WG draft and he has posted > > draft-ietf-tls-renegotiation-00 as a starting point. I realize that > > there are a number of people who aren't happy with aspects of the draft, > > or indeed with the draft as a whole, but I'd like to get the sense for > > the feelings of the group as a whole. If we have rough consensus that > > this is a workable approach, we can try to nail down the remaining > > issues and move forward. > > > > To try to keep this concrete, please respond with answers to this > > question: > > > > Support for the draft: > > - I support this draft > > - I support this draft with the following modification > > - I would support an entirely different proposal (please identify it; be > > specific) > > > > If you are proposing a modification, in addition to providing a > > description and rationale for a modification to the document it is > > helpful to provide sample text of the modification. Also, please > > indicate whether you would only support the draft with your modification > > or whether you can live with it unmodified. > > > > Firstly does this mean the 00 draft or the 01 one? > > I've mentioned elsewhere the fact that neither addresses SSLv2 or SSLv3 > compatible client hellos (which may well end up talking TLS but they don't > know > that initially) and talk of fallbacks doesn't address APIs or libraries > that > cannot transparently reconnect. > Which, to be clear, is probably most of them and certainly includes OpenSSL. > > I'm not really concerned how this is addressed. I would support the 01 > draft > with the following modifications: > > 1. The magic ciphersuite as well as being used as a fallback can be used on > initial connections if the client wishes to send an SSLv2 or SSLv3 > compatible > client hello or a TLS one without extensions. > > 2. Any server which accepts an SSLv2 or SSLv3 compatible client hello MUST > be > able to recognise the magic ciphersuite. > > Steve. > -- > Dr Stephen N. Henson. > Core developer of the OpenSSL project: http://www.openssl.org/ > Freelance consultant see: http://www.drh-consultancy.co.uk/ > Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0016e64f44f031dbd20478e6f075 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Nov 21, 2009 at 10:01 AM, Dr Ste= phen Henson <lists@drh-consultancy.demon.co.uk> wrote:
Joseph Salowey (jsalowey) wrote:
> We have had a lot of good discussion on this list, but I think we need=
> to start converging on a solution. As I said in a previous message, I&= #39;ve
> asked Eric to serve as editor for the WG draft and he has posted
> draft-ietf-tls-renegotiation-00 as a starting point. =A0I realize that=
> there are a number of people who aren't happy with aspects of the = draft,
> or indeed with the draft as a whole, but I'd like to get the sense= for
> the feelings of the group as a whole. If we have rough consensus that<= br> > this is a workable approach, we can try to nail down the remaining
> issues and move forward.
>
> To try to keep this concrete, please respond with answers to this
> question:
>
> Support for the draft:
> - I support this draft
> - I support this draft with the following modification
> - I would support an entirely different proposal (please identify it; = be
> specific)
>
> If you are proposing a modification, in addition to providing a
> description and rationale for a modification to the document it is
> helpful to provide sample text of the modification. Also, please
> indicate whether you would only support the draft with your modificati= on
> or whether you can live with it unmodified.
>

Firstly does this mean the 00 draft or the 01 one?

I've mentioned elsewhere the fact that neither addresses SSLv2 or SSLv3=
compatible client hellos (which may well end up talking TLS but they don= 9;t know
that initially) and talk of fallbacks doesn't address APIs or libraries= that
cannot transparently reconnect.

Which, to be clear= , is probably most of them and certainly includes OpenSSL.
=A0
=

I'm not really concerned how this is addressed. I would support the 01 = draft
with the following modifications:

1. The magic ciphersuite as well as being used as a fallback can be used on=
initial connections if the client wishes to send an SSLv2 or SSLv3 compatib= le
client hello or a TLS one without extensions.

2. Any server which accepts an SSLv2 or SSLv3 compatible client hello MUST = be
able to recognise the magic ciphersuite.

Steve.
--
Dr Stephen N. Henson.
Core developer of the =A0 OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consult= ancy.co.uk, PGP key: via homepage.
__________________________________= _____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--0016e64f44f031dbd20478e6f075-- From stefan@aaa-sec.com Sat Nov 21 12:47:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DFC3A6885 for ; Sat, 21 Nov 2009 12:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j8n8HzKZU9x for ; Sat, 21 Nov 2009 12:47:50 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id E63F73A6812 for ; Sat, 21 Nov 2009 12:47:49 -0800 (PST) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E630B28A216 for ; Sat, 21 Nov 2009 21:47:07 +0100 (CET) Received: (qmail 61984 invoked from network); 21 Nov 2009 20:47:00 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Nov 2009 20:47:00 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sat, 21 Nov 2009 21:46:58 +0100 From: Stefan Santesson To: David-Sarah Hopwood , Message-ID: Thread-Topic: [TLS] simplistic renego protection Thread-Index: Acpq68R/IhbsQRhlgUGW2NBK5v784Q== In-Reply-To: <4B0838E4.6010003@jacaranda.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 20:47:50 -0000 On 09-11-21 8:00 PM, "David-Sarah Hopwood" wrote: > > That's an oversimplification. > > The attacker is able to add a prefix to the server's view of the session. > This changes the server's state from what it would have been on an > initial connection. How far the attacker's influence on the server's > state extends into that session, is dependent on the application protocol. So we are saying the same thing. As you say, it depends on the application. What I claim is that it is possible to design an application that use channel binding to keep itself safe from this attack. All it needs to do is to make sure that it's state is reset after completed channel binding. The fact that it is possible to be safe despite this vulnerability is an argument that lenient servers should be supported in the solution. If I analyze my application and determine that it is safe from the attack, then I could just allow gradual upgrades and stay lenient. Or do you mean that it is impossible to design an application to be safe? /Stefan From stefan@aaa-sec.com Sat Nov 21 13:04:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0763A696E for ; Sat, 21 Nov 2009 13:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T835t8X80qJz for ; Sat, 21 Nov 2009 13:04:08 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 5F9603A68F7 for ; Sat, 21 Nov 2009 13:04:08 -0800 (PST) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D934E28CF58 for ; Sat, 21 Nov 2009 22:02:20 +0100 (CET) Received: (qmail 89953 invoked from network); 21 Nov 2009 21:02:12 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Nov 2009 21:02:12 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sat, 21 Nov 2009 22:02:09 +0100 From: Stefan Santesson To: Michael D'Errico , Message-ID: Thread-Topic: [TLS] Another critical problem with RI Thread-Index: Acpq7eN+YqHd7yw88kKvfZYHxxd/Kw== In-Reply-To: <4B072F1C.8050505@pobox.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Another critical problem with RI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 21:04:09 -0000 I think this is yet another argument for defining the "future" amended finished calculation now and apply it to both proposals, and simply reduce the discussion to different ways to do C->S and S->C signaling. Maybe we could even reduce the discussion to different ways to do S->C signaling (i.e. Always including the "magic" ciphersuite for C->S) and perhaps live with different ways of S->C for different protocol versions. /Stefan On 09-11-21 1:06 AM, "Michael D'Errico" wrote: > Here is yet another reason to reject Renegotiation_Info: > > The security of RI relies on implementations verifying that the data > carried in the extension is correct. It is possible for implementors > to get this wrong. A client or server could correctly get all of the > mechanics of sending and receiving the extension working but fail to > actually compare what they received to the old verify_data. Looking > at the bits-on-the-wire it will not be possible to tell that a client > or server is broken in this way. These broken implementations will > be able to perform initial connections and renegotiations. Such a > broken client paired with a broken server would still be vulnerable > to a MitM attack. > > Changing the Finished message calculation, on the other hand, is fool- > proof. Either you add the old verify_data to the handshake messages > or you don't. If you don't, then handshakes will fail regularly[*] > and the problem will be noticed and fixed. > > Note that adding the verify_data to the ClientHello.random and > ServerHello.random suffers from this same problem. > > Mike > > [*] To make this even more fool-proof, I suggest making sure that the > data added to the handshake message stream is never empty (i.e. as it > would be on an initial handshake in Martin's proposal); this can be > easily done by including length byte(s) or even a single fixed byte. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ynir@checkpoint.com Sat Nov 21 13:52:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918A73A6952 for ; Sat, 21 Nov 2009 13:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 uOR-CJY4ZAmM for ; Sat, 21 Nov 2009 13:52:08 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A967D3A688B for ; Sat, 21 Nov 2009 13:52:08 -0800 (PST) X-CheckPoint: {4B085D71-8-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BFD8F29C007; Sat, 21 Nov 2009 23:52:04 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A27EA29C002; Sat, 21 Nov 2009 23:52:04 +0200 (IST) X-CheckPoint: {4B085D71-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nALLq3Go020547; Sat, 21 Nov 2009 23:52:04 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 21 Nov 2009 23:52:10 +0200 From: Yoav Nir To: "Joseph Salowey (jsalowey)" Date: Sat, 21 Nov 2009 23:52:01 +0200 Thread-Topic: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: Acpq9OAS+MOFYxR/SMiy2fn9cVSLzA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org list" Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 21:52:09 -0000 On Nov 21, 2009, at 1:12 AM, Stefan Santesson wrote: > I would support an entirely different proposal that supports SSLv3 -> TLS > 1.2 using a common approach, I.e. Not using TLS extensions. >=20 > The condition is that the implementer community can agree on such approac= h > within a reasonable timeframe. >=20 > In absence of such agreement, I would support this draft. >=20 > /Stefan >=20 +1 Though I'm not sure why the implementer community (I'm one) would be quicke= r to agree on any approach than other people. From frantz@pwpconsult.com Sat Nov 21 14:04:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E76B3A6919 for ; Sat, 21 Nov 2009 14:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] 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 qZKrMV2dsJb2 for ; Sat, 21 Nov 2009 14:04:26 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5D4B43A67BD for ; Sat, 21 Nov 2009 14:04:26 -0800 (PST) Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NBy44-0002gx-9K; Sat, 21 Nov 2009 17:04:20 -0500 Date: Sat, 21 Nov 2009 14:04:33 -0800 From: Bill Frantz To: Ben Laurie X-Priority: 3 In-Reply-To: <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7939782feb6cbdf58fd9b7b1066d0875fd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.34 Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 22:04:27 -0000 benl@google.com (Ben Laurie) on Saturday, November 21, 2009 wrote: >The depends on those layers. If, for example, clients and servers simply >numbered their requests/responses, they would be immune to the attack. and stefan@aaa-sec.com (Stefan Santesson) on Saturday, November 21, 2009 wr= ote: >Or do you mean that it is impossible to design an application to be safe? While it is possible to design an application protocol which is safe, it isn't easy. For example, both the server and the client have to be using the same brackets. An attack on HTTP depends on allowing the MITM to cause the server to process a different GET/POST request from the one the client sent. This bracketing issue affects even protocols like the Waterken web-key protocol, where each request is self-authorizing. If the MITM has a resource on the server addressable with a web key, he can cause the client to pass parameter web-keys to that resource rather than the resource the client thought it was addressing. As a proof of concept that it is possible to design a safe protocol, if each request is digitally signed by the sender, and verified by the receiver, the MITM can not introduce superfluous data into the conversation. If the brackets are different, the signatures don't verify. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Airline peanut bag: "Produced | Periwinkle (408)356-8506 | in a facility that processes | 16345 Englewood Ave www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032 From djhopwood@googlemail.com Sat Nov 21 14:10:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568253A67E3 for ; Sat, 21 Nov 2009 14:10:03 -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 ERYGNTLv6tDN for ; Sat, 21 Nov 2009 14:10:02 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id DF9F53A67F5 for ; Sat, 21 Nov 2009 14:10:01 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so1231395eya.51 for ; Sat, 21 Nov 2009 14:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=dSjL/VcXqmJGZCghQoXAR/B41ROfC95hjns+MwKILJA=; b=x2fNJGnnCfG3kbNxiTNI4LpHo9OOm47GgWztpltLmab4LBQBKQgwqqHeH/yCHYWg/F hVTRSoLnyNwDc/UNFQMYOuwUy1KeEKaL3r68p6Dp1ZevezWcLxzhwboYm5sO8CwSsL76 D+ZuR+HExsu52Bq+oDlHIkmlWY/BD/85Ke9WM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=ugQMFZeOLAz3ef9Gi44atl52GfgybY73UmOdHBMNdQMhWkpEpzqRnanVP1stmX28cU 5d1cLVhTeANtfXIh3BhvuGHsTeqbUJ1K5h+w2T045GLIcItm3SqGOlWQwNGfRTNaJYmi w7L3Y2I35rmkWPKmIKFbK6ClmTNxeB6KXSvWA= Received: by 10.213.1.5 with SMTP id 5mr1769600ebd.71.1258841394903; Sat, 21 Nov 2009 14:09:54 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 16sm1319872ewy.10.2009.11.21.14.09.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 14:09:54 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B08650A.9090409@jacaranda.org> Date: Sat, 21 Nov 2009 22:09:14 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig22C0C688740A63788D437358" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 22:10:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig22C0C688740A63788D437358 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stefan Santesson wrote: > On 09-11-21 8:00 PM, "David-Sarah Hopwood" > wrote: >=20 >> That's an oversimplification. >> >> The attacker is able to add a prefix to the server's view of the sessi= on. >> This changes the server's state from what it would have been on an >> initial connection. How far the attacker's influence on the server's >> state extends into that session, is dependent on the application proto= col. >=20 > So we are saying the same thing. >=20 > As you say, it depends on the application. What I claim is that it is > possible to design an application that use channel binding to keep itse= lf > safe from this attack. All it needs to do is to make sure that it's sta= te is > reset after completed channel binding. That's not correct; it needs to know that the client's state is reset as well (see below). But suppose for the sake of argument, that both the cli= ent and server's state is reset when a renegotiation occurs. In that case, channel binding is a red herring. Resetting the client and server states prevents the attack regardless of channel binding. But then, why use renegotiation (and unnecessarily risk interoperability problems) if you'r= e going to use it in a way that is completely equivalent to making a new connection? > The fact that it is possible to be safe despite this vulnerability is a= n > argument that lenient servers should be supported in the solution. Suppose that an unpatched client performs a renegotiation. The server doesn't know whether this is an intended renegotiation or an attack; so, it must reset its state, as though the client had made a new connection. But with most application protocols, that won't work, because the client hasn't reset its state. It might work in some special cases, where the application protocol is stateless between requests (like HTTP) and the renegotiation occurred at a request boundary. But then, there is absolutely no advantage to using renegotiation; it's unnecessary complexity. One might argue: OK, renegotiation is unnecessary, but what if we want to= retain interoperability with clients that do it anyway (between stateless= requests, since that's the only case that would work)? However, in practi= ce clients don't renegotiate just for the fun of it; we need to consider how= renegotiation is actually used. I have not yet seen any plausible use cas= e for continuing to support renegotiation with unpatched clients, where it wouldn't be simpler and more secure to do something else (given that you'= re suggesting that we modify how the server uses the application protocol in= any case). For instance, when using renegotiation to prompt the client to= present a client cert, it's easier to have it make such requests on a different port. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig22C0C688740A63788D437358 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksIZR0ACgkQWUc8YzyzqAep1AD/TAcQS2nXF6WpMrjIpyyhYi/g vZivJZLNDmPfkJ+X58IA/0Kn8UlU39Y4nNO4JKZ6acoTM2bx1r8/iViemSSqLiw4 =uNxE -----END PGP SIGNATURE----- --------------enig22C0C688740A63788D437358-- From djhopwood@googlemail.com Sat Nov 21 14:19:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBBA23A6985 for ; Sat, 21 Nov 2009 14:19:26 -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 z6JRGxKgY112 for ; Sat, 21 Nov 2009 14:19:25 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 6C4ED3A68B1 for ; Sat, 21 Nov 2009 14:19:25 -0800 (PST) Received: by ewy6 with SMTP id 6so731763ewy.29 for ; Sat, 21 Nov 2009 14:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=FyssgRu1yo/S2vJT/GOEkfv1Z5HyJW1n6YgNgUwpzV0=; b=UPQKijVr+WgQafe3YbWMvRdkn+irYy3LwYfrnIxOnJ0n7PzadtcT50GI2a8LZdVVXP 9M3OMh+TpPATm0zJSmslPftF4VKLSu8xcuDU1nfDxCfJGMB4wZHJt++njBpHIRyAX3jX RKEBnkz0ZKxlMQmCQRpjZApBr+loyYG9F4qio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=L8SwQ8X5QisObGabkPoVYy+GK8IgM647VlEG6cx1eUdiLRDZ0nOdjG2vwTN2lTwEXW 9TxGq1qREkbhta9N+Mw9XQMDRiDgjH036ZG3GfnGsDHb65Y3wyb3hgyIuDpWjb2A3nMl a/HsiymXkrPMFcv1dElhte851RK6X1MJYmQ/Y= Received: by 10.213.110.17 with SMTP id l17mr1818923ebp.18.1258841958462; Sat, 21 Nov 2009 14:19:18 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 16sm1324850ewy.14.2009.11.21.14.19.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 14:19:17 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B086752.1030205@jacaranda.org> Date: Sat, 21 Nov 2009 22:18:58 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B06E2D7.2040302@jacaranda.org> <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> In-Reply-To: <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFC072E51D66E5FCF63EBBB88" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 22:19:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFC072E51D66E5FCF63EBBB88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ben Laurie wrote: > On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood < > david-sarah@jacaranda.org> wrote: >=20 >> Stefan Santesson wrote: >>> On 09-11-20 5:24 AM, "Michael D'Errico" wrote: >>> >>>> Some servers apparently cannot function without renegotiation. >>>> They will need to continue providing service to unpatched >>>> clients for some amount of time and thus remain vulnerable. >>> I fully agree, >>> >>> However, just because a server accepts renegotiation with an unpatche= d >>> client, does not necessarily mean that the service provided over TLS = is >>> vulnerable. >>> >>> One example is if authentication is performed with proper channel bin= ding >>> in a layer above TLS and the service is provided under that security >>> context. >> >> I'm skeptical. How can "proper channel binding" be done correctly in a= >> layer above TLS, if the TLS library merges renegotiated sessions? >> Since the session merging will result in the client and server's state= >> at the higher layer(s) being out of sync, nothing can be assumed about= >> the correct functioning of those layers. >=20 > The depends on those layers. If, for example, clients and servers simpl= y > numbered their requests/responses, they would be immune to the attack. That's not sufficient. They'd also have to make sure that renegotiation boundaries coincide with request/response boundaries. That requires that the app be notified by the TLS library precisely when a renegotiation occurs, and that individual reads and writes cannot extend across a renegotiation boundary. This contradicts the assumption that I stated explicitly above: "if the TLS library merges renegotiated sessions". It's also rather prone to application error even in cases where it would theoretically work. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFC072E51D66E5FCF63EBBB88 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksIZ1IACgkQWUc8YzyzqAeAtAEAgNfL96UZ4/NZ7xf5RMBZI9jI hu7oyah3Cnoo2Ex0cVcA/AqnZz/PoP8KJa7PVJZWzTGA2yGVEp46GP+AtcVkwoyi =iRFd -----END PGP SIGNATURE----- --------------enigFC072E51D66E5FCF63EBBB88-- From stefan@aaa-sec.com Sat Nov 21 14:58:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264EB3A68B1 for ; Sat, 21 Nov 2009 14:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzttV4zujI7f for ; Sat, 21 Nov 2009 14:58:51 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id E8D143A689F for ; Sat, 21 Nov 2009 14:58:50 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A055228A888 for ; Sat, 21 Nov 2009 23:58:54 +0100 (CET) Received: (qmail 31057 invoked from network); 21 Nov 2009 22:58:45 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Nov 2009 22:58:45 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sat, 21 Nov 2009 23:58:45 +0100 From: Stefan Santesson To: David-Sarah Hopwood , Message-ID: Thread-Topic: [TLS] simplistic renego protection Thread-Index: Acpq/i1v5mxv+1ndn0Wj1QPAoqhKqg== In-Reply-To: <4B08650A.9090409@jacaranda.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 22:58:52 -0000 I don't think this discussion is critical to selecting a solution, but one more go in-line; On 09-11-21 11:09 PM, "David-Sarah Hopwood" wrote: > Stefan Santesson wrote: >> On 09-11-21 8:00 PM, "David-Sarah Hopwood" >> wrote: >> >>> That's an oversimplification. >>> >>> The attacker is able to add a prefix to the server's view of the session. >>> This changes the server's state from what it would have been on an >>> initial connection. How far the attacker's influence on the server's >>> state extends into that session, is dependent on the application protocol. >> >> So we are saying the same thing. >> >> As you say, it depends on the application. What I claim is that it is >> possible to design an application that use channel binding to keep itself >> safe from this attack. All it needs to do is to make sure that it's state is >> reset after completed channel binding. > > That's not correct; it needs to know that the client's state is reset as > well (see below). Frankly, I can't see why it isn't enough for the server to reset it's state regardless of the client. The server will simply regard the first message after channel-binding as the first legitimate message from the client. > But suppose for the sake of argument, that both the client > and server's state is reset when a renegotiation occurs. In that case, > channel binding is a red herring. Resetting the client and server states > prevents the attack regardless of channel binding. The difference is that channel binding offers a safe point in time when you can do this reset. > But then, why use > renegotiation (and unnecessarily risk interoperability problems) if you're > going to use it in a way that is completely equivalent to making a new > connection? > I agree, you have a point here. The point is more that you don't need to take action to turn re-negotiation off if you are safe from the attack. >> The fact that it is possible to be safe despite this vulnerability is an >> argument that lenient servers should be supported in the solution. > > Suppose that an unpatched client performs a renegotiation. The server > doesn't know whether this is an intended renegotiation or an attack; so, > it must reset its state, No. If the renegotiation occurs after a successful channel binding, the server can be assured that this is not an attack. So the server will reset it's state after channel binding but not on following renegotiations. > as though the client had made a new connection. > But with most application protocols, that won't work, because the client > hasn't reset its state. > > It might work in some special cases, where the application protocol is > stateless between requests (like HTTP) and the renegotiation occurred > at a request boundary. But then, there is absolutely no advantage to > using renegotiation; it's unnecessary complexity. > > One might argue: OK, renegotiation is unnecessary, but what if we want to > retain interoperability with clients that do it anyway (between stateless > requests, since that's the only case that would work)? However, in practice > clients don't renegotiate just for the fun of it; we need to consider how > renegotiation is actually used. I have not yet seen any plausible use case > for continuing to support renegotiation with unpatched clients, where it > wouldn't be simpler and more secure to do something else (given that you're > suggesting that we modify how the server uses the application protocol in > any case). For instance, when using renegotiation to prompt the client to > present a client cert, it's easier to have it make such requests on a > different port. You might be absolutely right here. However, I think the burden of proof should be reversed. Lenient servers should be supported unless we know for sure that there is no legitimate use case. It should be the choice of the local administrator to be strict, not the choice of the protocol designer. IMO, if one solution can support of lenient servers, and the other proposal can't then the one that can has merit. /Stefan From marsh@extendedsubset.com Sat Nov 21 15:05:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7835A3A69C8 for ; Sat, 21 Nov 2009 15:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 TIqnsmFBSy6A for ; Sat, 21 Nov 2009 15:05:01 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A73583A692C for ; Sat, 21 Nov 2009 15:05:01 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NBz0k-000KYj-4k; Sat, 21 Nov 2009 23:04:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BA4D8667C; Sat, 21 Nov 2009 23:04:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/lHjFtb4ijwZEv75onTzyZSIKMMdc6b/A= Message-ID: <4B087216.3010803@extendedsubset.com> Date: Sat, 21 Nov 2009 17:04:54 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ben Laurie References: <4B06E2D7.2040302@jacaranda.org> <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> In-Reply-To: <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 23:05:02 -0000 Ben Laurie wrote: > > On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood > > wrote: > > I'm skeptical. How can "proper channel binding" be done correctly in a > layer above TLS, if the TLS library merges renegotiated sessions? > Since the session merging will result in the client and server's state > at the higher layer(s) being out of sync, nothing can be assumed about > the correct functioning of those layers. > > > The depends on those layers. If, for example, clients and servers simply > numbered their requests/responses, they would be immune to the attack. MitM may be able to prep the client to match the sequence number of the server at the point of splicing. - Marsh From mistone@akamai.com Sat Nov 21 17:11:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760013A6A40 for ; Sat, 21 Nov 2009 17:11:52 -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 s17KbHahgWLc for ; Sat, 21 Nov 2009 17:11:49 -0800 (PST) Received: from prod-mail-xrelay04.akamai.com (prod-mail-xrelay04.akamai.com [96.6.114.79]) by core3.amsl.com (Postfix) with ESMTP id 6570B3A6A31 for ; Sat, 21 Nov 2009 17:11:48 -0800 (PST) Received: from prod-mail-xrelay04.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AEF2E51001D for ; Sun, 22 Nov 2009 01:11:42 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (unknown [172.23.253.93]) by prod-mail-xrelay04.akamai.com (Postfix) with ESMTP id 7CBE6510015 for ; Sun, 22 Nov 2009 01:11:42 +0000 (GMT) Received: from usma1mc-aa5yjx.akamai.com (usma1mc-aa5yjx.kendall.corp.akamai.com [172.19.114.139]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id D4CEE1000091 for ; Sun, 22 Nov 2009 01:11:41 +0000 (GMT) Received: by usma1mc-aa5yjx.akamai.com (Postfix, from userid 29263) id 4D4E29F8F92; Sat, 21 Nov 2009 20:11:41 -0500 (EST) From: Michael Stone To: tls In-reply-to: <20091120000001.7D25D3A6840@core3.amsl.com> References: <20091120000001.7D25D3A6840@core3.amsl.com> Date: Sat, 21 Nov 2009 20:11:36 -0500 Message-Id: <1258852287-sup-9453@usma1mc-aa5yjx> User-Agent: Sup/0.8.1 Content-Transfer-Encoding: 8bit Content-Type: multipart/signed; micalg="pgp-sha1"; boundary="=-1258852301-269906-62122-3403-79-="; protocol="application/pgp-signature" MIME-Version: 1.0 Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 01:11:55 -0000 --=-1258852301-269906-62122-3403-79-= Content-Type: text/plain; charset= Dear TLS Working Group members, My colleagues and I at Akamai have pooled our experience serving a large fraction of the web's traffic to identify several novel considerations affecting your proposals, notably concerning unforeseen social constraints on ciphersuites, the need to live with our decisions for many years, and the risk of combinatorial explosion of protocols. I hope you find them helpful in reaching a prompt and effective consensus. Kind regards, Michael Stone ........... New Ciphersuites ---------------- We foresee some adoption hazards facing new "ciphersuites" which have not been mentioned so far. In particular, while additional ciphersuite identifiers may be very *technically* interoperable among SSL and TLS implementations, they are regularly the subject of contractual language or technical guidance which may make them socially expensive to adopt. For example, the "Client Browser Requirements" section of the US DISA's guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that must be enabled and disabled. Similarly, it seems likely that many contracts have been written which mandate the use of FIPS 140-2-approved ciphers, e.g., in order to establish compliance with the vague PCI-DSS "strong cryptography" requirement. Thus, care should be taken to find out how much social infrastructure will need to be updated in order to permit the use of this signalling mechanism. Protocol versioning and support ------------------------------- Due to customer demand, we currently expect to need to support unmodified versions of all of SSL3, TLS 1.0, 1.1, 1.2, and even (against our recommendations) SSL2, for many years. This brings up three sub-points: First, because we're going to have to support legacy protocols for the indefinite future, we would prefer to see a single new protocol with safe renegotiation semantics (e.g. TLS 1.3) over seeing many new protocols branched from all the old protocols. We are particularly interested in heading off the combinatorial explosion of new TLS protocols that might result from the future discovery of new vulnerabilities if "protocol branching" is adopted. Second, we believe that changing the definition of the Finished message should not be done without increasing the protocol version number. Third, we believe the proposed solution of "upgrade all SSL3 clients to TLS" to be unrealistic in general. That is, while "upgrade all SSL3 clients to TLS" may be good advice for browsers and for many other SSL3 clients on the public internet, we are sensitive to the enormous variety of circumstances in which SSL3 is deployed and would be saddened to see the this working group leave behind end-users who require renegotiation and who are unable to upgrade to TLS but who could nevertheless manage to apply a minimally invasive change to their legacy SSL3 implementation. In this vein, legacy embedded systems such as cell phones, game consoles, TV set top boxes, old PDAs, and other such devices particularly concern us: we expect them to be difficult and time-consuming to update if updating is even possible. The current draft-ietf-tls-renegotiation-00 specification seems to largely ignore the prevalence of these devices, to the detriment of vulnerable end-users and of the server operators who must cater to them. --=-1258852301-269906-62122-3403-79-= Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAksIj8gACgkQdi/cbxLH7ckE2ACfV12AOL/SFMcR5c/EHepGBKpS qVoAnAmfpOE2NGyAIjeFh4A9T8i9Al8r =0xNl -----END PGP SIGNATURE----- --=-1258852301-269906-62122-3403-79-=-- From thamil@cisco.com Sat Nov 21 17:19:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32693A6A46 for ; Sat, 21 Nov 2009 17:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 BAvUD2KEYkWa for ; Sat, 21 Nov 2009 17:19:42 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ED9ED3A6A45 for ; Sat, 21 Nov 2009 17:19:42 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAYhCEtAaHte/2dsb2JhbAC8PJcCgkWBdwSDAQ X-IronPort-AV: E=Sophos;i="4.47,265,1257120000"; d="scan'208";a="107671832" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2009 01:19:32 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAM1JV8b004426; Sun, 22 Nov 2009 01:19:31 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 06:49:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Nov 2009 06:49:29 +0530 Message-ID: <0D25A594A60CDD45A1A00FCD1F88E7F80173FB52@XMB-BGL-414.cisco.com> In-Reply-To: <200911200501.nAK517WH015650@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acppno+afdXC11QiR32XLyIH4+a7igBcadeg References: <4B0588F7.7090107@drh-consultancy.demon.co.uk> from "Dr StephenHenson" at Nov 19, 9 06:05:43 pm <200911200501.nAK517WH015650@fs4113.wdf.sap.corp> From: "Thamilarasu Kandasamy (thamil)" To: , "Dr Stephen Henson" X-OriginalArrivalTime: 22 Nov 2009 01:19:31.0495 (UTC) FILETIME=[D7F05B70:01CA6B11] Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 01:19:44 -0000 Being able to verify the authenticity of the source of a message at the earliest state of negotiation is better for many reasons. When a renegotiation is initiated, there is a state already, by leveraging some info from state, we should have a way to do it. I have the following suggestion, "Client and Server can keep track of the number of Change Cipher Spec messages they have sent. During renegotiation, client is in possession of server's public key. It could encrypt the count of CCS messages and add as an extension to the ClientHello message. Server could use this to verify whether it receives message from the same source." DTLS, defined in RFC4347, has a header field, epoch, that increments with every CCS. TLS too can keep track of CCS msgs and leverage it to plug the gap in the authentication as exposed by this vulnerability. Thanks Thamil > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Martin Rex > Sent: Friday, November 20, 2009 10:31 AM > To: Dr Stephen Henson > Cc: tls@ietf.org > Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas >=20 > Dr Stephen Henson wrote: > > > > Martin Rex wrote: > > > > > > > > >> Yes, we might be missing something else. The reason I picked the > Certificate > > >> message is that it is dynamic size by default, so we don't have to > alter > > >> existing data, just append. > > > > > > To me that feels very wrong to use the Certificate message. > > > I'm convinced that it should go into the ServerHello. I'm not > > > questioning that ServerHello is the correct place for all of the > > > cryptographic parameters _and_ the TLS extensions. > > > > > > > Well in terms of implementation and overhead I'd prefer that the > client > > knows as soon as possible which method to use. The need to maintain > two > > hash contexts (or cache some potentially long handshake messages) and > > always throwing one away is IMHO not trivial. >=20 > This is why I favour the approach with adding the verify_data > of the finished messages directly after ServerHello, > because that is where the "negotiation"/signaling is completed > both peers can determine how to proceed, no assumptions > necessary, no keeping multiple hashes around. >=20 > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mike-list@pobox.com Sat Nov 21 18:02:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA163A677D for ; Sat, 21 Nov 2009 18:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 7C0TJdIkXj0h for ; Sat, 21 Nov 2009 18:02:40 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 1502D3A681A for ; Sat, 21 Nov 2009 18:02:40 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 55E7181D4B for ; Sat, 21 Nov 2009 21:02:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rIKe/mfdS9gN ST+BywDXhuIT744=; b=dI0j47FkseRFAgp9Ab/tPNveAue2IzezxlK56bklDGbJ JhSzTH1lMZdf0jM2r8qOVrPjTHuE6G8ldR+dH/y/fmBr5nZQKSRzAi9fJmROYYjc yfykV/iorZD8WAiqYlI9Cf624VPrA26zYevbHr2zoUlV344XOIIu3JnZu8uWOPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=QtOkpL 8h4XOgucwq3/5hsdOcIFglmj2zGur4iZqFrfsMgf9+CDfdVIIMH9Z8aNmXFHcBef oFreFkqjSgd+wxzy4DlWRDPrA2HVRi/coV++MyteVPLLETpd9A6KnkZVxJdj8+B6 Ab6yR0kJTUQTuXM7XXDKWQIjvgcjzo9wl9zIo= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5270D81D49 for ; Sat, 21 Nov 2009 21:02:35 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id E0DCC81D48 for ; Sat, 21 Nov 2009 21:02:34 -0500 (EST) Message-ID: <4B089C16.1050508@pobox.com> Date: Sat, 21 Nov 2009 18:04:06 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B0588F7.7090107@drh-consultancy.demon.co.uk> from "Dr StephenHenson" at Nov 19, 9 06:05:43 pm <200911200501.nAK517WH015650@fs4113.wdf.sap.corp> <0D25A594A60CDD45A1A00FCD1F88E7F80173FB52@XMB-BGL-414.cisco.com> In-Reply-To: <0D25A594A60CDD45A1A00FCD1F88E7F80173FB52@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 1A4545CA-D70B-11DE-9B9D-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 02:02:41 -0000 Hi Thamil, Thanks for the suggestion, but there is a problem in that not all public keys support encryption. DSA keys, for example, can only be used to verify digital signatures. Another potential problem is if the attacker can somehow synchronize the client and server such that their values for the epoch match, they would continue with the handshake. Keep the suggestions coming, Mike Thamilarasu Kandasamy (thamil) wrote: > Being able to verify the authenticity of the source of a message at the > earliest state of negotiation is better for many reasons. When a > renegotiation is initiated, there is a state already, by leveraging some > info from state, we should have a way to do it. I have the following > suggestion, > > "Client and Server can keep track of the number of Change Cipher Spec > messages they have sent. During renegotiation, client is in possession > of server's public key. It could encrypt the count of CCS messages and > add as an extension to the ClientHello message. Server could use this > to verify whether it receives message from the same source." > > DTLS, defined in RFC4347, has a header field, epoch, that increments > with every CCS. TLS too can keep track of CCS msgs and leverage it to > plug the gap in the authentication as exposed by this vulnerability. > > Thanks > Thamil > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Martin Rex >> Sent: Friday, November 20, 2009 10:31 AM >> To: Dr Stephen Henson >> Cc: tls@ietf.org >> Subject: Re: [TLS] Proposal for hybrid solution using most of the > ideas >> Dr Stephen Henson wrote: >>> Martin Rex wrote: >>>> >>>>> Yes, we might be missing something else. The reason I picked the >> Certificate >>>>> message is that it is dynamic size by default, so we don't have > to >> alter >>>>> existing data, just append. >>>> To me that feels very wrong to use the Certificate message. >>>> I'm convinced that it should go into the ServerHello. I'm not >>>> questioning that ServerHello is the correct place for all of the >>>> cryptographic parameters _and_ the TLS extensions. >>>> >>> Well in terms of implementation and overhead I'd prefer that the >> client >>> knows as soon as possible which method to use. The need to maintain >> two >>> hash contexts (or cache some potentially long handshake messages) > and >>> always throwing one away is IMHO not trivial. >> This is why I favour the approach with adding the verify_data >> of the finished messages directly after ServerHello, >> because that is where the "negotiation"/signaling is completed >> both peers can determine how to proceed, no assumptions >> necessary, no keeping multiple hashes around. >> >> -Martin >> _______________________________________________ >> 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 mike-list@pobox.com Sat Nov 21 18:17:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C674B3A6847 for ; Sat, 21 Nov 2009 18:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 0Pvr59ryLhWR for ; Sat, 21 Nov 2009 18:17:48 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id A853C3A677D for ; Sat, 21 Nov 2009 18:17:47 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E910D81E45; Sat, 21 Nov 2009 21:17:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=AK9Bnxxx9qRK t3E+SzOfDMbLIb0=; b=i9m3qyOtt4mbJ7EE9+/6QlL/ZpN6mH9EOVfyUWHk9m0q W9TdxridI7LuJILvs4rAxUQRtlDUSgv4v2ygrB5vv1Z+KbP2DOxm0/Y7FYhOQENk x4jLzx6FK6igA4vUss8iaVwD/NfWnRqbuB9lL74YkO98QsTSxqdEa7JLCLgYZVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=n9sMeU GqhvY+OI9a3g6J2zO//ZQNcetOjlAtojkbbJb7Wk1XdhByt580Ex1ouPlrF3mL4Y dD5AsTTzh//l25NGCJYVUd+lE+T1W2NDyiobwFQWZCqDnejLa2/0c0xMY5j+eZuT jvxfVpTltmVSs5yFnvPQzFaX+W7Y4kDpy3og8= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D831E81E44; Sat, 21 Nov 2009 21:17:42 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 1A16A81E43; Sat, 21 Nov 2009 21:17:40 -0500 (EST) Message-ID: <4B089FA0.5060900@pobox.com> Date: Sat, 21 Nov 2009 18:19:12 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Michael Stone References: <20091120000001.7D25D3A6840@core3.amsl.com> <1258852287-sup-9453@usma1mc-aa5yjx> In-Reply-To: <1258852287-sup-9453@usma1mc-aa5yjx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 372EE63A-D70D-11DE-94AC-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Cc: tls Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 02:17:49 -0000 Hi Michael, Thanks for this valuable feedback. I'm having difficulty trying to understand your recommendations which appear to be contradictory: You say that you'd prefer that safe renegotiation be implemented only in a new version, i.e. TLS 1.3, especially if the Finished message calculation changes. But then you also say that it is unreasonable to expect SSLv3 clients to upgrade to TLS, and that you will be supporting old versions for many years to come (all of which would remain vulnerable based on the fact that only TLS 1.3 would be fixed). I would add that it would be difficult for even TLS 1.0 code to be upgraded all the way to TLS 1.3 -- you would need to implement TLS 1.1, 1.2, and 1.3. I've implemented them all and it requires many hundreds, or even thousands of lines of code. The problem is that you can't skip versions (if you're the client) because the server might select one that you skipped, and thus you would have an interoperability problem. If we don't patch the existing versions, many will remain vulnerable due to the effort required to get all the way to TLS 1.3. Can you please clarify your recommendations? Thanks, Mike Michael Stone wrote: > Dear TLS Working Group members, > > My colleagues and I at Akamai have pooled our experience serving a large > fraction of the web's traffic to identify several novel considerations > affecting your proposals, notably concerning unforeseen social constraints on > ciphersuites, the need to live with our decisions for many years, and the risk > of combinatorial explosion of protocols. I hope you find them helpful in > reaching a prompt and effective consensus. > > Kind regards, > > Michael Stone > > ........... > > New Ciphersuites > ---------------- > > We foresee some adoption hazards facing new "ciphersuites" which have not been > mentioned so far. > > In particular, while additional ciphersuite identifiers may be very > *technically* interoperable among SSL and TLS implementations, they are > regularly the subject of contractual language or technical guidance which may > make them socially expensive to adopt. > > For example, the "Client Browser Requirements" section of the US DISA's > guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that must > be enabled and disabled. Similarly, it seems likely that many contracts have > been written which mandate the use of FIPS 140-2-approved ciphers, e.g., in > order to establish compliance with the vague PCI-DSS "strong cryptography" > requirement. > > Thus, care should be taken to find out how much social infrastructure will need > to be updated in order to permit the use of this signalling mechanism. > > Protocol versioning and support > ------------------------------- > > Due to customer demand, we currently expect to need to support unmodified > versions of all of SSL3, TLS 1.0, 1.1, 1.2, and even (against our > recommendations) SSL2, for many years. This brings up three sub-points: > > First, because we're going to have to support legacy protocols for the > indefinite future, we would prefer to see a single new protocol with safe > renegotiation semantics (e.g. TLS 1.3) over seeing many new protocols branched > from all the old protocols. We are particularly interested in heading off the > combinatorial explosion of new TLS protocols that might result from the future > discovery of new vulnerabilities if "protocol branching" is adopted. > > Second, we believe that changing the definition of the Finished message should > not be done without increasing the protocol version number. > > Third, we believe the proposed solution of "upgrade all SSL3 clients to TLS" > to be unrealistic in general. > > That is, while "upgrade all SSL3 clients to TLS" may be good advice for > browsers and for many other SSL3 clients on the public internet, we are > sensitive to the enormous variety of circumstances in which SSL3 is deployed > and would be saddened to see the this working group leave behind end-users who > require renegotiation and who are unable to upgrade to TLS but who could > nevertheless manage to apply a minimally invasive change to their legacy SSL3 > implementation. > > In this vein, legacy embedded systems such as cell phones, game consoles, TV > set top boxes, old PDAs, and other such devices particularly concern us: we > expect them to be difficult and time-consuming to update if updating is even > possible. The current draft-ietf-tls-renegotiation-00 specification seems to > largely ignore the prevalence of these devices, to the detriment of vulnerable > end-users and of the server operators who must cater to them. From mrex@sap.com Sat Nov 21 18:24:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73723A68E1 for ; Sat, 21 Nov 2009 18:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.139, 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 eUoqMuZDSsnB for ; Sat, 21 Nov 2009 18:24:36 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B87183A683D for ; Sat, 21 Nov 2009 18:24:35 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAM2OTF5012424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Nov 2009 03:24:29 +0100 (MET) From: Martin Rex Message-Id: <200911220224.nAM2OSYD011390@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Sun, 22 Nov 2009 03:24:28 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Nov 21, 9 09:46:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 02:24:36 -0000 Stefan Santesson wrote: > > What I claim is that it is possible to design an application that > use channel binding to keep itself safe from this attack. > All it needs to do is to make sure that it's state is reset > after completed channel binding. > > The fact that it is possible to be safe despite this vulnerability is an > argument that lenient servers should be supported in the solution. > > If I analyze my application and determine that it is safe from the attack, > then I could just allow gradual upgrades and stay lenient. If it just was that easy. In addition to the TLS renegotiation vulnerability there may be unexpected consequences of the architecture of the API that is used between the TLS implementation and the application. The particular problem with HTTP is, that it does not authenticate the request as first thing in the protocol when Cookie-based or basic authentication is used, which makes that particular attack successful. When TLS client-certs are used it may actually become _a_lot_worse_ because the TLS authentication is not tied to a specific request, but instead is supposed to authenticate the entire channel and all data that travels it. Here is where HTTP 1.1 Connection: Keep-alive significantly expands an attackers options. If no client-certs are used and the authentication is performed inside the application data as the first thing in the request, then this app might not be vulnerable. I can't comment on the "application that use channel binding" though, because I don't understand that concept yet. If the app uses some crypto stuff outside of regular TLS to digitally sign or protect each request with a keyed hash based on cryptographic properties of the TLS channel (like the finished messages), then this could work. But the problem that I see there is the layering. TLS is supposed to go directly on top of TCP. If the application several layers above TLS uses properties such as a finished message for a keyed hash on individual requests, then I don't see how this could work well in a distributed environment, where the original TLS channel might be terminated at the perimeter of the distributed backend system (server farm), while the backend application runs on some backend machine far away from the endpoint of the TLS channel. A layering violation of that kind puts significant constraints on the (absence of compexity of) the infrastructure where it might be used. -Martin From mrex@sap.com Sat Nov 21 18:58:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271B83A679C for ; Sat, 21 Nov 2009 18:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.137, 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 upEdyG1xyB3D for ; Sat, 21 Nov 2009 18:58:38 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D50563A683D for ; Sat, 21 Nov 2009 18:58:37 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAM2wUIg002728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Nov 2009 03:58:30 +0100 (MET) From: Martin Rex Message-Id: <200911220258.nAM2wUCE013636@fs4113.wdf.sap.corp> To: mistone@akamai.com (Michael Stone) Date: Sun, 22 Nov 2009 03:58:30 +0100 (MET) In-Reply-To: <1258852287-sup-9453@usma1mc-aa5yjx> from "Michael Stone" at Nov 21, 9 08:11:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 02:58:39 -0000 Michael Stone wrote: > > New Ciphersuites > ---------------- > > We foresee some adoption hazards facing new "ciphersuites" which > have not been mentioned so far. > > In particular, while additional ciphersuite identifiers may be very > *technically* interoperable among SSL and TLS implementations, they are > regularly the subject of contractual language or technical guidance > which may make them socially expensive to adopt. > > For example, the "Client Browser Requirements" section of the US DISA's > guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that must > be enabled and disabled. Similarly, it seems likely that many contracts have > been written which mandate the use of FIPS 140-2-approved ciphers, e.g., in > order to establish compliance with the vague PCI-DSS "strong cryptography" > requirement. > > Thus, care should be taken to find out how much social infrastructure will > need to be updated in order to permit the use of this signalling mechanism. There seems to be a serious misunderstanding! We are definitely _not_ talking about enabling new ciphersuites. What we are talking about is magic ciphersuite IDs to steer protocol behaviour. There will be a SHOULD in the spec that this magic ciphersuite ID should NOT be configurable and neither reported at normal ciphersuite configuration APIs and UIs, only visible in the network encoding of the ClientHello handshake message, and there will be a requirement in the spec that the Server MUST NOT select this magic cipher suite ID as the common cipher suite -- because it is not a cipher suite. > > Protocol versioning and support > ------------------------------- > > Due to customer demand, we currently expect to need to support unmodified > versions of all of SSL3, TLS 1.0, 1.1, 1.2, and even (against our > recommendations) SSL2, for many years. This brings up three sub-points: > > First, because we're going to have to support legacy protocols for the > indefinite future, we would prefer to see a single new protocol with safe > renegotiation semantics (e.g. TLS 1.3) over seeing many new protocols branched > from all the old protocols. We are particularly interested in heading off the > combinatorial explosion of new TLS protocols that might result from the future > discovery of new vulnerabilities if "protocol branching" is adopted. Another misunderstanding. We are not branching any protocols. We are fixing a security vulnerability in an existing protocol. Just like service packs or hotfixes does not convert your Windows OS into new products, this fix for a security vulnerability will not create a different protocol--only a patched/fixed version of it. But of course, should we find another security vulnerability in the protocol then we would have to think once again how to fix it. The difference between an implementation bug and a protocol defect is, that unless you can live with disabling the affected protocol feature entirely, you will have to change the protocol that will usually change some bits-on-the-wire. > > Second, we believe that changing the definition of the Finished message > should not be done without increasing the protocol version number. Yet another misunderstanding. I haven't seen anyone talking about changing the definition of the Finished message. What we have been discussing is how to get an authentication of the current session included in the authentication performed by the Finished message of the renegotiation. The only way to do that is to get the verify_data from the Finished messages of the current session included in the handshake message hash. What we are fighting about is the exact API calls that we are going to use to achieve that, and whether we should also change and add some fairly static bytes in two handshake messages on the way or prefer a simpler, straightforward and failSAFE fashion. > > Third, we believe the proposed solution of "upgrade all SSL3 clients to TLS" > to be unrealistic in general. Wow, that sounds challenging. What about the all new TLSv1.3 you're looking for -- what would be the purpose of that if you are going to leave most of the installed base as it is? The creation of a TLSv1.3 spec is not going to magically heal old implementations that do not want to or can not get upgraded. > > That is, while "upgrade all SSL3 clients to TLS" may be good advice for > browsers and for many other SSL3 clients on the public internet, we are > sensitive to the enormous variety of circumstances in which SSL3 is deployed > and would be saddened to see the this working group leave behind end-users who > require renegotiation and who are unable to upgrade to TLS but who could > nevertheless manage to apply a minimally invasive change to their legacy SSL3 > implementation. > > In this vein, legacy embedded systems such as cell phones, game consoles, TV > set top boxes, old PDAs, and other such devices particularly concern us: we > expect them to be difficult and time-consuming to update if updating is even > possible. The current draft-ietf-tls-renegotiation-00 specification seems to > largely ignore the prevalence of these devices, to the detriment of vulnerable > end-users and of the server operators who must cater to them. Personally, I do care a lot about the installed base, including the stuff that is likely not to be updated at all. Not all of that will be vulnerable. But those that are, there's nothing TLS WG can do to protect them unless there is a way to patch their implementations. Firewalling that stuff might sometimes be an option. -Martin From djhopwood@googlemail.com Sat Nov 21 20:16:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56953A6853 for ; Sat, 21 Nov 2009 20:16:14 -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 UVE5cKvsIbL1 for ; Sat, 21 Nov 2009 20:16:13 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 618443A677D for ; Sat, 21 Nov 2009 20:16:13 -0800 (PST) Received: by ewy6 with SMTP id 6so847033ewy.29 for ; Sat, 21 Nov 2009 20:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=kFTEEkwPCQa1ID8xwhrPQWwcoB2WsqXIZaFpe5qS2Co=; b=H1Iu/ZHJrssLjSTmpFb1EPmnjdM4yql5/QJ6k5vg9jbl2PsHBMvPcxmuB0RfElx7og kXLuge9HWms6ILE0dXqVZp/9034041wDuQ4w0+BTZZ0UsnRpN/Wrfq6YFyFenIf7pqgg Wxa6yFqE+rqEOfFsHfrdZbtoyOcTYzqeMoMls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=S+e6BzcfWQqIiElPeH8n5FeRRO6s3+iCDN+7FoZXeCAN5LpfY8TpeG6l7S98Cm+CXq 7JvoGOh/cjgJZph7X0Bq6kP2AjY5AQY9ERoaOoboHgvIu+N5GAsYXpSEgsZgWSPsqkkO kApdvB01sb9rUWcckuvN/LNXttpADgqpcVTa0= Received: by 10.213.96.6 with SMTP id f6mr3123508ebn.31.1258863369537; Sat, 21 Nov 2009 20:16:09 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 13sm1400699ewy.1.2009.11.21.20.16.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 20:16:08 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B08BAE3.3020803@jacaranda.org> Date: Sun, 22 Nov 2009 04:15:31 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0588F7.7090107@drh-consultancy.demon.co.uk> from "Dr StephenHenson" at Nov 19, 9 06:05:43 pm <200911200501.nAK517WH015650@fs4113.wdf.sap.corp> <0D25A594A60CDD45A1A00FCD1F88E7F80173FB52@XMB-BGL-414.cisco.com> In-Reply-To: <0D25A594A60CDD45A1A00FCD1F88E7F80173FB52@XMB-BGL-414.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4EC906B03EE6291BC24581F0" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 04:16:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4EC906B03EE6291BC24581F0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thamilarasu Kandasamy (thamil) wrote: > Being able to verify the authenticity of the source of a message at the= > earliest state of negotiation is better for many reasons. When a > renegotiation is initiated, there is a state already, by leveraging som= e > info from state, we should have a way to do it. I have the following > suggestion, >=20 > "Client and Server can keep track of the number of Change Cipher Spec > messages they have sent. During renegotiation, client is in possession= > of server's public key. It could encrypt the count of CCS messages and= > add as an extension to the ClientHello message. Server could use this > to verify whether it receives message from the same source." How does including this count provide any benefit over using the verify_data values, that act as a unique identifier for the previous session? --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig4EC906B03EE6291BC24581F0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksIuuoACgkQWUc8YzyzqAfH7wD/Qmn/a48UExZLskN/qrBArED3 I/hRzXlYQ7RFGvuqT1wA/i7mRZtzQUkjPZNpYbEZkhxhdYtNp8cMRODr6HQMC+bw =PLs/ -----END PGP SIGNATURE----- --------------enig4EC906B03EE6291BC24581F0-- From djhopwood@googlemail.com Sat Nov 21 20:39:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD4C3A686B for ; Sat, 21 Nov 2009 20:39:26 -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 6S+kElwFQHMj for ; Sat, 21 Nov 2009 20:39:25 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 145DB3A679C for ; Sat, 21 Nov 2009 20:39:24 -0800 (PST) Received: by ewy6 with SMTP id 6so852539ewy.29 for ; Sat, 21 Nov 2009 20:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=PhQygKQYMvOesT9v9XUTvS90y2lf+CGlY1xIU1wN0/s=; b=oMqPIN9rZPYwWQVX072jqeek+LyFezw1RTGPFMKgw65nc03WFXRB7CYv7P/TIf8t+L vyaEGc4NftJoD9u/frgH9t9fNXOtwcOLrJNXW7yY0ntZ3YZeoo+Gh5SSNjyvZbIK/YDi HcBcGeRmJVY/yZGQKKBjf3Yi5DW/GFJ2Mo544= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=DmXglrok6sywMlgh1E20Zwz96UeTg5rD214mcjoDDTFPrxdWuXHdV67ZNJ395M3lJ+ R0ADy1jgP9/tqRfKfzWOlq4tjk4U0zvgLcpHBye7BIGJ7AJwVoDUf0MtrIzbqkzxs0mW T6Wmg+KqlMma3GxZv4pGixW2cWZD8JBgWS5M4= Received: by 10.213.27.8 with SMTP id g8mr2046030ebc.58.1258864758216; Sat, 21 Nov 2009 20:39:18 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 13sm571049ewy.9.2009.11.21.20.39.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 20:39:17 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B08C04E.4070606@jacaranda.org> Date: Sun, 22 Nov 2009 04:38:38 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF0FCE1864CC81F2B83F36A21" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 04:39:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0FCE1864CC81F2B83F36A21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stefan Santesson wrote: > On 09-11-21 11:09 PM, "David-Sarah Hopwood" = > wrote: >> Stefan Santesson wrote: >>> On 09-11-21 8:00 PM, "David-Sarah Hopwood" >>> wrote: >>>> >>>> The attacker is able to add a prefix to the server's view of the ses= sion. >>>> This changes the server's state from what it would have been on an >>>> initial connection. How far the attacker's influence on the server's= >>>> state extends into that session, is dependent on the application pro= tocol. >>> So we are saying the same thing. >>> >>> As you say, it depends on the application. What I claim is that it is= >>> possible to design an application that use channel binding to keep it= self >>> safe from this attack. All it needs to do is to make sure that it's s= tate is >>> reset after completed channel binding. >> >> That's not correct; it needs to know that the client's state is reset = as >> well (see below). >=20 > Frankly, I can't see why it isn't enough for the server to reset it's s= tate > regardless of the client. The server will simply regard the first messa= ge > after channel-binding as the first legitimate message from the client. The data sent on the channel is only split into "messages" at the application protocol layer (if at all). At the upper interface of the TLS layer, it is just a duplex byte stream, so the client may have sent a= partial application message. The server will then receive the rest of tha= t message after having reset its state, so it will be out of sync with the client. This situation would break the application protocol regardless of= any attack. >> But then, why use >> renegotiation (and unnecessarily risk interoperability problems) if yo= u're >> going to use it in a way that is completely equivalent to making a new= >> connection? >=20 > I agree, you have a point here. The point is more that you don't need t= o > take action to turn re-negotiation off if you are safe from the attack.= But you do have to take action to ensure that the server resets its state= , and/or perform channel binding. Given that you have to take action, it's not at all clear that these particular actions are simpler than the alternatives; in they are definitely more complex than some alternatives.= >>> The fact that it is possible to be safe despite this vulnerability is= an >>> argument that lenient servers should be supported in the solution. >> >> Suppose that an unpatched client performs a renegotiation. The server >> doesn't know whether this is an intended renegotiation or an attack; s= o, >> it must reset its state, >=20 > No. If the renegotiation occurs after a successful channel binding, the= > server can be assured that this is not an attack. Your suggestion was that channel binding could be done above the TLS laye= r. As far as I can see, any channel binding that occurs above the TLS layer cannot work to prevent the attack unless it is aware of the TLS renegotiation boundaries. If you think that it can, please give more deta= il of the protocol you're proposing; "successful channel binding" is not a specific enough description. [...] >> One might argue: OK, renegotiation is unnecessary, but what if we want= to >> retain interoperability with clients that do it anyway (between statel= ess >> requests, since that's the only case that would work)? However, in pra= ctice >> clients don't renegotiate just for the fun of it; we need to consider = how >> renegotiation is actually used. I have not yet seen any plausible use = case >> for continuing to support renegotiation with unpatched clients, where = it >> wouldn't be simpler and more secure to do something else (given that y= ou're >> suggesting that we modify how the server uses the application protocol= in >> any case). For instance, when using renegotiation to prompt the client= to >> present a client cert, it's easier to have it make such requests on a >> different port. >=20 > You might be absolutely right here. However, I think the burden of proo= f > should be reversed. Lenient servers should be supported unless we know = for > sure that there is no legitimate use case. It should be the choice of t= he > local administrator to be strict, not the choice of the protocol design= er. >=20 > IMO, if one solution can support of lenient servers, and the other prop= osal > can't then the one that can has merit. Well, I've previously proposed a solution that supported lenient servers (changing the Finished hashes unconditionally on a renegotiation, but usi= ng extensions for signalling). That doesn't change my mind that a lenient server policy is a bad idea. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigF0FCE1864CC81F2B83F36A21 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksIwFYACgkQWUc8YzyzqAe8bQD/WbY7bk75fqs20wSfht3tTXIy g4o49IGQ1cwqBtJE9ZcA+wbZOAmoweMHp7f0Xo/kgLc7psWV5xYdwz/jk8lxmyuw =PL1m -----END PGP SIGNATURE----- --------------enigF0FCE1864CC81F2B83F36A21-- From djhopwood@googlemail.com Sat Nov 21 21:05:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82623A6853 for ; Sat, 21 Nov 2009 21:05:36 -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 I-2U0VGZd8Bt for ; Sat, 21 Nov 2009 21:05:35 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 90F823A6809 for ; Sat, 21 Nov 2009 21:05:34 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so1262534eya.51 for ; Sat, 21 Nov 2009 21:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=5ZITNmCjOlnB5rff2DYB97p2KdnSlsxmBB1blaJ08VU=; b=r0+4KbRZKCpSIIEUfLwzkskXRtpUdKJnKguo4kgxTTYyNMHwKYIPM8RKvJaEPri+Xp /yHlm7DpXwIab/TVwioHeFX1Xm476lwVtIXaWGj/pL3XgkF8NZ5Wk0weOMUOoGMusEVF EWADG+wg8VHCv49cJAwXa5+Q5pB3kSx4YYXMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=PEfGA9WquBzj1dkOv1+psnUPpm6kjgvUL4OLIDaezZTSdLCaKgIrB3GoAz6+RfhK9Z oA/8Ecm88y4kyxJgdDBdEBbyFXn5AmTlNPFCk5BkAUrk9KfogVre+D61YAhleI4MGaDy Ik4m9OuGrtTZyV27G9c/Kjazbluex7rEMZQCs= Received: by 10.213.23.201 with SMTP id s9mr3195894ebb.72.1258866326716; Sat, 21 Nov 2009 21:05:26 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 16sm1415411ewy.14.2009.11.21.21.05.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 21:05:26 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B08C670.803@jacaranda.org> Date: Sun, 22 Nov 2009 05:04:48 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <20091120000001.7D25D3A6840@core3.amsl.com> <1258852287-sup-9453@usma1mc-aa5yjx> In-Reply-To: <1258852287-sup-9453@usma1mc-aa5yjx> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5C7BDDE6EB7055B8089E8059" Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 05:05:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C7BDDE6EB7055B8089E8059 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael Stone wrote: > Due to customer demand, we currently expect to need to support unmodifi= ed > versions of all of SSL3, TLS 1.0, 1.1, 1.2, and even (against our > recommendations) SSL2, for many years. Note that SSLv2 is vulnerable to a MITM attack that forces use of 40-bit crypto. It is certainly not possible to fix this. So, support for SSLv2 should not be a consideration; if a client or server negotiates SSLv2, then it is already making itself vulnerable to an attack as serious as the renegotiation attack (since it is now easy to break 40-bit crypto). And if a client doesn't intend to negotiate SSLv2, then there's no point in sending an SSLv2-compatible ClientHello, so we don't need to consider that case either. > Second, we believe that changing the definition of the Finished message= should > not be done without increasing the protocol version number. I disagree. This is imposing an artificial requirement that over-constrai= ns the solution. If the solution must support several existing versions (and= I don't think anyone disagrees that it must support at least TLS 1.0, 1.1= and 1.2), and changing the Finished message should not be done without increasing the version number, then this is just saying that the Finished= message computation can't be changed. Note that the only approach put forward so far that does not explicitly change the Finished computation is the RI draft. > Third, we believe the proposed solution of "upgrade all SSL3 clients to= TLS" > to be unrealistic in general.=20 Since the RI draft requires the client to send a TLS ClientHello, the cli= ent must support TLS (or break the widespread and justified assumption made b= y servers that a client sending a TLS ClientHello is able to negotiate TLS)= =2E So, your second and third points together exclude *every* proposal so far= , and it is not obvious that any solution under these constraints is possib= le. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig5C7BDDE6EB7055B8089E8059 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksIxncACgkQWUc8YzyzqAdcFQD8DL63nP/ODZjQib8pEj8E6Ukc LAwA/wfrPB595Xxl5FgA/RggvvEo/3Tt9Oh+GUHZ8UnU0Jr8320Es2l+Lwb1eK6d =+AoU -----END PGP SIGNATURE----- --------------enig5C7BDDE6EB7055B8089E8059-- From nelson@bolyard.me Sat Nov 21 21:23:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623773A67D8 for ; Sat, 21 Nov 2009 21:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 8aRCVpplPyL1 for ; Sat, 21 Nov 2009 21:23:02 -0800 (PST) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id 63DFB3A65A5 for ; Sat, 21 Nov 2009 21:23:02 -0800 (PST) Received: (qmail 2303 invoked from network); 22 Nov 2009 05:22:57 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 22 Nov 2009 05:22:57 -0000 Message-ID: <4B08CA3C.7020503@bolyard.me> Date: Sat, 21 Nov 2009 21:21:00 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 05:23:03 -0000 On 2009-11-20 13:53 PST, Joseph Salowey (jsalowey) wrote: > We have had a lot of good discussion on this list, but I think we need > to start converging on a solution. As I said in a previous message, I've > asked Eric to serve as editor for the WG draft and he has posted > draft-ietf-tls-renegotiation-00 as a starting point. > To try to keep this concrete, please respond with answers to this > question: > > Support for the draft: > - I support this draft > - I support this draft with the following modification I support this draft, and request modifications similar to the following, which (I believe) are merely clarifying in nature, and do not change the over-the-wire specification any. I do not require these exact modifications, but something like them would help a lot. Page 6 section 3: - Upon receipt of the "renegotiation_info" extension, implementations + Upon receipt of the "renegotiation_info" extension, both client and + server implementations which support the extension MUST verify that it contains the correct contents as specified above. Page 6, section 4.1: - If a client offers the "renegotiation_info" extension and the server - does not respond, then this indicates that the server either does not + If a client hello offers the "renegotiation_info" extension (hereinafter + abbreviated RI) and the server does not offer an RI extension in the + server hello response, then this indicates that the server either does + not Page 7, section 4.2: - If the client does not offer the "renegotiation_info" extension, then + If the client hello does not offer the "renegotiation_info" extension, + and does not contain the "RENEGOTIATE_WITH_RI" cipher suite, then (Note, this resolves an ambiguity. Otherwise, the requirements of section 4.2 seem to apply also when "RENEGOTIATE_WITH_RI is present, which section 4.1.1 requires to be dealt with in a different manner. The suggested change keeps these requirements of the two sections from overlapping.) Page 7, section 4.3: - SSLv3 does not support extensions and thus it is not possible to Both + Both SSLv3 (at least later drafts) and TLS 1.0/1.1 require implementations Page 8, section 4.3 (top of page): - extensions since the ordinarily TLS Finished messages protect that + extensions since the ordinary TLS Finished messages protect that negotiation. Page 8, section 4.3: best practice is not to continue the connection. Even servers which - refuse to renegotiate SHOULD reply with an empty RI extension because + refuse to renegotiate SHOULD reply with an empty RI extension in the + server hello of the connection's initial handshake because this signals that they have been upgraded. (This clarifies where and when they should reply with that empty RI extension, since they CANNOT do it in the refused renegotiation.) Page 8, section 5: By default, TLS implementations conforming to this document MUST - verify that once an identity has been authenticated within the TLS - handshake, it does not change on subsequent renegotiations. + verify that once the peer has been identified and authenticated within + the TLS handshake, the identity does not change on subsequent + renegotiations. From djhopwood@googlemail.com Sat Nov 21 21:31:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CA83A67A4 for ; Sat, 21 Nov 2009 21:31:37 -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 ZUJDhdezGJUU for ; Sat, 21 Nov 2009 21:31:33 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id B11583A67D8 for ; Sat, 21 Nov 2009 21:31:32 -0800 (PST) Received: by ewy6 with SMTP id 6so864755ewy.29 for ; Sat, 21 Nov 2009 21:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=eEGzxAfYRtMrKcPpUxjhQtmh/GrVh44BP8BNwGh5v60=; b=TzGGlMzLKH3UciBlSHV6qIakK2FmOgraRAFjoti2FAYP0UdxDPKukvOQrcn1qRsVvF JXG80C3G/NUolrNFkPXYZLaCs4nwYbAhpLLS5Krfz384X/yVzRl7NhmTDMoeM6hYKOKh Sy2hyvNQDiAqsghAPUbohKjvYvBx+g7KBu2vE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=PSbpDrJOXP6uT1b9xq2oK5pCoi11UoWFK0cZxAz0xDCgEeN7nX1glHYGAXnOsjwQqs 5Lokf1ocTOxjaj95Cy2fSh53J/eVNv2V2jtt5KH/MDiCq8xtl9Ntodmt/LzujjH//oJL 2y2TCL3ksnH6soQFvGT76Ed7LKs2rvCCyqWxQ= Received: by 10.213.100.168 with SMTP id y40mr2068542ebn.28.1258867885904; Sat, 21 Nov 2009 21:31:25 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 15sm1021641ewy.12.2009.11.21.21.31.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 21:31:25 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B08CC80.7070305@jacaranda.org> Date: Sun, 22 Nov 2009 05:30:40 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911220258.nAM2wUCE013636@fs4113.wdf.sap.corp> In-Reply-To: <200911220258.nAM2wUCE013636@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFF6C371089040EF0FBB4295C" Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 05:31:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF6C371089040EF0FBB4295C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Michael Stone wrote: >> First, because we're going to have to support legacy protocols for the= >> indefinite future, we would prefer to see a single new protocol with s= afe >> renegotiation semantics (e.g. TLS 1.3) over seeing many new protocols = branched >> from all the old protocols. We are particularly interested in heading = off the >> combinatorial explosion of new TLS protocols that might result from th= e future >> discovery of new vulnerabilities if "protocol branching" is adopted. >=20 > Another misunderstanding. We are not branching any protocols. > We are fixing a security vulnerability in an existing protocol. >=20 > Just like service packs or hotfixes does not convert your Windows OS > into new products, this fix for a security vulnerability will not > create a different protocol--only a patched/fixed version of it. >=20 > But of course, should we find another security vulnerability > in the protocol then we would have to think once again how to fix it. Note that, even if additional vulnerabilities were found, that would not lead to any combinatorial explosion of variants. That's because the fix for any version-independent flaw can and should require implementation of all the fixes for previously discovered version-independent flaws. In that case, the number of variants is at most (number of SSL/TLS versions) * (number of flaws + 1). A combinatorial explosion would be something like (number of SSL/TLS versions) * 2^(number of flaws), but that would only occur if implementation of each fix was independent, and there's no reason to allow that. >> Second, we believe that changing the definition of the Finished messag= e >> should not be done without increasing the protocol version number. >=20 > Yet another misunderstanding. > I haven't seen anyone talking about changing the definition of the > Finished message. I think that's a perfectly reasonable option, for example: verify_data =3D PRF(master_secret, finished_label, Hash(handshake_messages), previous_verify_data) [0..verify_data_length-1]; and I see no reason to exclude this option from consideration. Note that this would obviate any confusion about where the previous_verify_data goes in the handshake messages, or how it is encoded. More importantly, it guarantees that that the input to the PRF for the modified Finished computation cannot coincide with any possible input for the unmodified computation, which is a useful property that simplifies the security analysis. > What we have been discussing is how to get an authentication of > the current session included in the authentication performed by > the Finished message of the renegotiation. >=20 > The only way to do that is to get the verify_data from the Finished > messages of the current session included in the handshake message > hash. No, it isn't, as shown above. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFF6C371089040EF0FBB4295C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksIzI0ACgkQWUc8YzyzqAfhewD+PnjmQGx0RZll/Mpw9Ge6iB/L nFsUhDBhq5/weLaRF6UA/iBD2ZpOMm3rzhefh291CmKR6OrPP02l06hoORWn9P0c =78qy -----END PGP SIGNATURE----- --------------enigFF6C371089040EF0FBB4295C-- From nelson@bolyard.me Sat Nov 21 21:33:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08A93A67A4 for ; Sat, 21 Nov 2009 21:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.308, 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 G6byoJzlinpe for ; Sat, 21 Nov 2009 21:33:18 -0800 (PST) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id AC2B93A65A5 for ; Sat, 21 Nov 2009 21:33:18 -0800 (PST) Received: (qmail 8334 invoked from network); 22 Nov 2009 05:33:12 -0000 Received: from unknown (24.5.142.42) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 22 Nov 2009 05:33:12 -0000 Message-ID: <4B08CCA3.3050104@bolyard.me> Date: Sat, 21 Nov 2009 21:31:15 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Dr Stephen Henson References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> <4B059658.2010200@extendedsubset.com> <4B07EA2B.5040809@drh-consultancy.demon.co.uk> In-Reply-To: <4B07EA2B.5040809@drh-consultancy.demon.co.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 05:33:20 -0000 On 2009-11-21 05:24 PST, Dr Stephen Henson wrote: > Just to add a point to this which hasn't really been mentioned. > > The discussion of connection logic has largely been browser centric, > non-browser clients often work in a different way and the current > proposal (draft-ietf-tls-renegotiation-01.txt) can cause them significant > problems. Where is this draft? It's not on rfc-editor.org nor on ietf.org. Are you referring to draft-RESCORLA-tls-renegotiation-01.txt? From djhopwood@googlemail.com Sat Nov 21 21:39:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF343A67A4 for ; Sat, 21 Nov 2009 21:39:00 -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 Dzdw-Ow3WMBO for ; Sat, 21 Nov 2009 21:38:59 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 541EF3A67FC for ; Sat, 21 Nov 2009 21:38:59 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so1264414eya.51 for ; Sat, 21 Nov 2009 21:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=YfjhVN7gPQDLOyJp/Z2Vuu7SUjjvOtpV9kpq6oYRgus=; b=Z6RoCSTfxpqsgh7wnaWoEo6OSKQkl1hzYwVR8OCWruSVVShOTMzAXKgO2NnUDgvIp/ A8qCoqgJOinCQpfbOkXe9PQd0zx9kOHnv5bgiv6hHS2qVB0+Ox60UQHQoRHmF+k1saIS iD/VOhhsFmgse/YLuOKMSB4MgWIAYreqMTYnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=XKQGZ7I4fhvIN9kzNiDRUD7gIrv5QXNZSr7943J8rIDNRCT9U77DncUPtNSH+fIGps rXrkgU8cK3icDsxK2/jb6Fu2Mi/GJckhv0q12zvTrRN/04ciPtRyCYB+TBDTddAa/fJP o7byUW/Wrk1Ni8V6wQRfTtkzbvzic5CQ41wqQ= Received: by 10.213.0.154 with SMTP id 26mr3217560ebb.82.1258868332398; Sat, 21 Nov 2009 21:38:52 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 15sm1028906ewy.8.2009.11.21.21.38.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 21:38:51 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B08CE47.90906@jacaranda.org> Date: Sun, 22 Nov 2009 05:38:15 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911220258.nAM2wUCE013636@fs4113.wdf.sap.corp> <4B08CC80.7070305@jacaranda.org> In-Reply-To: <4B08CC80.7070305@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBE9451CBFF6A46C9A7CA573F" Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 05:39:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBE9451CBFF6A46C9A7CA573F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Note that, even if additional vulnerabilities were found, that would no= t > lead to any combinatorial explosion of variants. That's because the fix= > for any version-independent flaw can and should require implementation > of all the fixes for previously discovered version-independent flaws. > In that case, the number of variants is at most > (number of SSL/TLS versions) * (number of flaws + 1). Actually, if you consider each implementation to support a contiguous range of versions, then the number of variants is N*(N+1)/2 * (number of flaws + 1). where N is the number of SSL/TLS versions. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigBE9451CBFF6A46C9A7CA573F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksIzkcACgkQWUc8YzyzqAd+TgEAkGxNNODzWHweA5lWaOg9B7pF ZQ69n8gD9GnlxmST+lEA/A2y/mXFn6ygnUrlnjiiNbVctT7i+/CG4dgs+FZ42ihC =fGdS -----END PGP SIGNATURE----- --------------enigBE9451CBFF6A46C9A7CA573F-- From djhopwood@googlemail.com Sat Nov 21 22:29:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647EC3A68EA for ; Sat, 21 Nov 2009 22:29:54 -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 hKGrafxwhyTW for ; Sat, 21 Nov 2009 22:29:53 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id C7CF93A68E6 for ; Sat, 21 Nov 2009 22:29:52 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so1267261eya.51 for ; Sat, 21 Nov 2009 22:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=HkSWVcXnLLkO3x/QvjeVkw+QZ6az8f22gTwSVXSc41U=; b=V31BNW8BvEmC2u8q4140Oifpk0gH86FbDsa/sVSM/RdaZHBqZuFc/lQGVSLTzfKnT1 BP9ED3muSxpV4UF3a7YbUfdBmRNroRATMmXjR//okCa9b89ouDWAdBThpNp1iboRPU/X t7AnXLrdOInzOTl5cuTWpHUOxo3IUFlbNOe/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=ENEpNLdHFf1x0yjARfbPUjCqpZtkkIQ0SHMXx4kJk+2fTVjQwjvctfxUCO3j9rJhuJ UTaoZQd0PNTlyZU5epBgcIBJRy4MkmEnbcZJsFZuGjH/zcGT4vtEgr3IJoaGJcp21nd3 xu5BzrBfj4zowjW0NI34bvgGCzWUt0d3IXvTs= Received: by 10.216.87.144 with SMTP id y16mr1071914wee.95.1258871384337; Sat, 21 Nov 2009 22:29:44 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 5sm366232eyf.10.2009.11.21.22.29.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 22:29:43 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B08DA36.90101@jacaranda.org> Date: Sun, 22 Nov 2009 06:29:10 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911220258.nAM2wUCE013636@fs4113.wdf.sap.corp> <4B08CC80.7070305@jacaranda.org> In-Reply-To: <4B08CC80.7070305@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig54F63F4350D1823E4E471100" Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 06:29:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig54F63F4350D1823E4E471100 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Martin Rex wrote: >> Michael Stone wrote: >>> Second, we believe that changing the definition of the Finished messa= ge >>> should not be done without increasing the protocol version number. >> >> Yet another misunderstanding. >> I haven't seen anyone talking about changing the definition of the >> Finished message. >=20 > I think that's a perfectly reasonable option, for example: >=20 > verify_data =3D > PRF(master_secret, finished_label, Hash(handshake_messages), > previous_verify_data) > [0..verify_data_length-1]; Minor notational error -- that should be verify_data =3D PRF(master_secret, finished_label, Hash(handshake_messages) + previous_verify_data) [0..verify_data_length-1]; > and I see no reason to exclude this option from consideration. Note tha= t > this would obviate any confusion about where the previous_verify_data > goes in the handshake messages, or how it is encoded. More importantly,= > it guarantees that that the input to the PRF for the modified Finished > computation cannot coincide with any possible input for the unmodified > computation, which is a useful property that simplifies the security > analysis. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig54F63F4350D1823E4E471100 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksI2jYACgkQWUc8YzyzqAcVZQD/bBCOA2pZcqlB9EeR/c8rmu67 B6RQmMKpVfnIVTD43NMBAISMcsYj7xGvR7kZh28ArvCgSgXiIMbmJ5n7lfD8r6/c =YYZZ -----END PGP SIGNATURE----- --------------enig54F63F4350D1823E4E471100-- From ynir@checkpoint.com Sun Nov 22 00:40:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B4B3A6A3B for ; Sun, 22 Nov 2009 00:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 D0oMcwJXKOXD for ; Sun, 22 Nov 2009 00:40:47 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0D6243A6A39 for ; Sun, 22 Nov 2009 00:40:46 -0800 (PST) X-CheckPoint: {4B08F572-3-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A6E9929C004; Sun, 22 Nov 2009 10:40:42 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 89B3B29C002; Sun, 22 Nov 2009 10:40:42 +0200 (IST) X-CheckPoint: {4B08F572-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAM8efGo011313; Sun, 22 Nov 2009 10:40:42 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 22 Nov 2009 10:40:48 +0200 From: Yoav Nir To: Michael Stone Date: Sun, 22 Nov 2009 10:40:40 +0200 Thread-Topic: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt Thread-Index: AcprT31RbjF8kgsBSymTiMmqD5b6+g== Message-ID: <8A7ED133-F3A2-4574-A49F-EB48393FA3C0@checkpoint.com> References: <20091120000001.7D25D3A6840@core3.amsl.com> <1258852287-sup-9453@usma1mc-aa5yjx> In-Reply-To: <1258852287-sup-9453@usma1mc-aa5yjx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tls Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 08:40:48 -0000 On Nov 22, 2009, at 3:11 AM, Michael Stone wrote: > Protocol versioning and support > ------------------------------- >=20 > Due to customer demand, we currently expect to need to support unmodified > versions of all of SSL3, TLS 1.0, 1.1, 1.2, and even (against our > recommendations) SSL2, for many years. This brings up three sub-points: >=20 > First, because we're going to have to support legacy protocols for the > indefinite future, we would prefer to see a single new protocol with safe > renegotiation semantics (e.g. TLS 1.3) over seeing many new protocols bra= nched > from all the old protocols. We are particularly interested in heading off= the > combinatorial explosion of new TLS protocols that might result from the f= uture > discovery of new vulnerabilities if "protocol branching" is adopted. >=20 > Second, we believe that changing the definition of the Finished message s= hould > not be done without increasing the protocol version number. I agree with both points, but the semantics of the SSLv3/TLS handshake are = such, that you can't declare that you support SSLv3 or TLS 1.3 only. Many i= mplementations (OpenSSL comes to mind) only have SSLv2, SSLv3 and TLS 1.0. = Updating them to support TLS 1.3 would require adding support for TLS 1.1 = and TLS 1.2 as well. That would take longer to implement and much longer fo= r acceptance tests. Also, a new version of TLS may affect all those contrac= ts you mentioned earlier even more than a new ciphersuite. >=20 > Third, we believe the proposed solution of "upgrade all SSL3 clients to T= LS" > to be unrealistic in general.=20 >=20 > That is, while "upgrade all SSL3 clients to TLS" may be good advice for > browsers and for many other SSL3 clients on the public internet, we are > sensitive to the enormous variety of circumstances in which SSL3 is deplo= yed > and would be saddened to see the this working group leave behind end-user= s who > require renegotiation and who are unable to upgrade to TLS but who could > nevertheless manage to apply a minimally invasive change to their legacy = SSL3 > implementation.=20 Agree, but you can't change any client from vulnerable to not-vulnerable, u= nless you do one of three things: - implement the new binding (new Finished message) - receive a signal that the gateway is patched, and won't renegotiate with= you, and failing that...=20 - not connect to un-patched servers. >=20 > In this vein, legacy embedded systems such as cell phones, game consoles,= TV > set top boxes, old PDAs, and other such devices particularly concern us: = we > expect them to be difficult and time-consuming to update if updating is e= ven > possible. The current draft-ietf-tls-renegotiation-00 specification seems= to > largely ignore the prevalence of these devices, to the detriment of vulne= rable > end-users and of the server operators who must cater to them. But what can we do? They are vulnerable. If they don't require reneg, a go= od server will protect them by not renegotiating at all. If they do, they'r= e just vulnerable, and it's the server's choice as to whether to protect th= em or not. From lists@drh-consultancy.demon.co.uk Sun Nov 22 04:50:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16FC3A6A06 for ; Sun, 22 Nov 2009 04:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 behZ0oUBDJut for ; Sun, 22 Nov 2009 04:50:45 -0800 (PST) Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by core3.amsl.com (Postfix) with ESMTP id 056EF3A6836 for ; Sun, 22 Nov 2009 04:50:44 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49233 helo=[192.168.7.8]) by relay00.mail.eu.clara.net (relay.clara.net [213.253.3.40]:10587) with esmtpa (authdaemon_plain:drh) id 1NCBtl-0005u8-1k (Exim 4.69) (return-path ); Sun, 22 Nov 2009 12:50:38 +0000 Message-ID: <4B09339D.7080108@drh-consultancy.demon.co.uk> Date: Sun, 22 Nov 2009 12:50:37 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nelson B Bolyard References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> <4B059658.2010200@extendedsubset.com> <4B07EA2B.5040809@drh-consultancy.demon.co.uk> <4B08CCA3.3050104@bolyard.me> In-Reply-To: <4B08CCA3.3050104@bolyard.me> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 12:50:46 -0000 Nelson B Bolyard wrote: > On 2009-11-21 05:24 PST, Dr Stephen Henson wrote: > >> Just to add a point to this which hasn't really been mentioned. >> >> The discussion of connection logic has largely been browser centric, >> non-browser clients often work in a different way and the current >> proposal (draft-ietf-tls-renegotiation-01.txt) can cause them significant >> problems. > > Where is this draft? It's not on rfc-editor.org nor on ietf.org. > Are you referring to draft-RESCORLA-tls-renegotiation-01.txt? > Yes I meant the 01 version at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt Fallbacks aren't explicitly mentioned in the 00 draft. The whole issue of how one can support secure renegotiation (if the server supports it) but still connect to an unpatched SSLv3 or unpatched extension intolerant TLS server isn't covered. The 01 draft resolves this issue but requires fallbacks. It has been mentioned elsewhere that the obvious fallback techniques using the 00 draft are vulnerable to downgrade attacks. If anyone has a reference to a fallback technique that isn't vulnerable and complies to the 00 draft I'd be interested to hear it. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From uri@ll.mit.edu Sun Nov 22 05:46:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022F83A68C9 for ; Sun, 22 Nov 2009 05:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPRdCQrOlheF for ; Sun, 22 Nov 2009 05:46:22 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 259233A6833 for ; Sun, 22 Nov 2009 05:46:21 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAMDkHhT002045; Sun, 22 Nov 2009 08:46:17 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAHgaqHc; Sun Nov 22 08:43:57 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Sun, 22 Nov 2009 08:43:57 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'david-sarah@jacaranda.org'" , "'tls@ietf.org'" Date: Sun, 22 Nov 2009 08:43:45 -0500 Thread-Topic: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt Thread-Index: AcprPTMYMuJvgVAARQONXxRro45RigAPKL/K Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F3A@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 13:46:23 -0000 U291bmRzIGxpa2UgYSByZWFzb25hYmxlIG9wdGlvbi4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQpGcm9tOiB0bHMtYm91bmNlc0BpZXRmLm9yZyA8dGxzLWJvdW5jZXNAaWV0Zi5v cmc+DQpUbzogdGxzQGlldGYub3JnIDx0bHNAaWV0Zi5vcmc+DQpTZW50OiBTdW4gTm92IDIyIDAx OjI5OjEwIDIwMDkKU3ViamVjdDogUmU6IFtUTFNdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi10bHMt cmVuZWdvdGlhdGlvbi0wMC50eHQNCg0KRGF2aWQtU2FyYWggSG9wd29vZCB3cm90ZToNCj4gTWFy dGluIFJleCB3cm90ZToNCj4+IE1pY2hhZWwgU3RvbmUgd3JvdGU6DQo+Pj4gU2Vjb25kLCB3ZSBi ZWxpZXZlIHRoYXQgY2hhbmdpbmcgdGhlIGRlZmluaXRpb24gb2YgdGhlIEZpbmlzaGVkIG1lc3Nh Z2UNCj4+PiBzaG91bGQgbm90IGJlIGRvbmUgd2l0aG91dCBpbmNyZWFzaW5nIHRoZSBwcm90b2Nv bCB2ZXJzaW9uIG51bWJlci4NCj4+DQo+PiBZZXQgYW5vdGhlciBtaXN1bmRlcnN0YW5kaW5nLg0K Pj4gSSBoYXZlbid0IHNlZW4gYW55b25lIHRhbGtpbmcgYWJvdXQgY2hhbmdpbmcgdGhlIGRlZmlu aXRpb24gb2YgdGhlDQo+PiBGaW5pc2hlZCBtZXNzYWdlLg0KPiANCj4gSSB0aGluayB0aGF0J3Mg YSBwZXJmZWN0bHkgcmVhc29uYWJsZSBvcHRpb24sIGZvciBleGFtcGxlOg0KPiANCj4gICB2ZXJp ZnlfZGF0YSA9DQo+ICAgICBQUkYobWFzdGVyX3NlY3JldCwgZmluaXNoZWRfbGFiZWwsIEhhc2go aGFuZHNoYWtlX21lc3NhZ2VzKSwNCj4gICAgICAgICBwcmV2aW91c192ZXJpZnlfZGF0YSkNCj4g ICAgICAgWzAuLnZlcmlmeV9kYXRhX2xlbmd0aC0xXTsNCg0KTWlub3Igbm90YXRpb25hbCBlcnJv ciAtLSB0aGF0IHNob3VsZCBiZQ0KDQogICAgdmVyaWZ5X2RhdGEgPQ0KICAgICAgUFJGKG1hc3Rl cl9zZWNyZXQsIGZpbmlzaGVkX2xhYmVsLCBIYXNoKGhhbmRzaGFrZV9tZXNzYWdlcykNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyBwcmV2aW91c192ZXJpZnlfZGF0 YSkNCiAgICAgICAgWzAuLnZlcmlmeV9kYXRhX2xlbmd0aC0xXTsNCg0KPiBhbmQgSSBzZWUgbm8g cmVhc29uIHRvIGV4Y2x1ZGUgdGhpcyBvcHRpb24gZnJvbSBjb25zaWRlcmF0aW9uLiBOb3RlIHRo YXQNCj4gdGhpcyB3b3VsZCBvYnZpYXRlIGFueSBjb25mdXNpb24gYWJvdXQgd2hlcmUgdGhlIHBy ZXZpb3VzX3ZlcmlmeV9kYXRhDQo+IGdvZXMgaW4gdGhlIGhhbmRzaGFrZSBtZXNzYWdlcywgb3Ig aG93IGl0IGlzIGVuY29kZWQuIE1vcmUgaW1wb3J0YW50bHksDQo+IGl0IGd1YXJhbnRlZXMgdGhh dCB0aGF0IHRoZSBpbnB1dCB0byB0aGUgUFJGIGZvciB0aGUgbW9kaWZpZWQgRmluaXNoZWQNCj4g Y29tcHV0YXRpb24gY2Fubm90IGNvaW5jaWRlIHdpdGggYW55IHBvc3NpYmxlIGlucHV0IGZvciB0 aGUgdW5tb2RpZmllZA0KPiBjb21wdXRhdGlvbiwgd2hpY2ggaXMgYSB1c2VmdWwgcHJvcGVydHkg dGhhdCBzaW1wbGlmaWVzIHRoZSBzZWN1cml0eQ0KPiBhbmFseXNpcy4NCg0KLS0gDQpEYXZpZC1T YXJhaCBIb3B3b29kICDimqUgIGh0dHA6Ly9kYXZpZHNhcmFoLmxpdmVqb3VybmFsLmNvbQ0KDQo= From stpeter@stpeter.im Sun Nov 22 10:38:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48893A69DA for ; Sun, 22 Nov 2009 10:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 3vwYCHP6n1UC for ; Sun, 22 Nov 2009 10:38:40 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AA6FD3A6980 for ; Sun, 22 Nov 2009 10:38:40 -0800 (PST) Received: from squire.local (dsl-175-187.dynamic-dsl.frii.net [216.17.175.187]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 94E2B40D09; Sun, 22 Nov 2009 11:38:36 -0700 (MST) Message-ID: <4B09852B.6010300@stpeter.im> Date: Sun, 22 Nov 2009 11:38:35 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911201828.nAKISN6Y017007@fs4113.wdf.sap.corp> In-Reply-To: <200911201828.nAKISN6Y017007@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070603020705040102000106" Cc: tls@ietf.org Subject: Re: [TLS] RC4+3DES rekeying - long-lived TLS connections X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 18:38:41 -0000 This is a cryptographically signed message in MIME format. --------------ms070603020705040102000106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/20/09 11:28 AM, Martin Rex wrote: > Peter Saint-Andre wrote: >> ... For example in XMPP >> we use long-lived TCP connections and, on top of those, long-lived XML >> streams that can be TLS-protected. In practice, for server-to-server >> federation (and even for client-to-server communication) those >> connections might be up for days, weeks, even months. At this point the >> handling of long-lived XML streams is unspecified, but I would expect >> most XMPP servers to terminate the connection and force the other party >> to reconnect. > > There was a discussion around long-lived SSL connections and > reasons for rekeying, e.g. using TLS renegotiation on mogul-open. > > If you're using ciphersuites with RC4 or 3DES encryption algorithms, > you probably should not use such connections for prolonged times > or huge amounts of data without rekeying (see below). Thanks for the tip. We'll do some research about this in the XMPP WG. > The other issue: if you're authenticating such a connection once > based on X.509 certificates and leave it open for month, you might > want to talk to the PKIX folks about this. > > They might feel uneasy if you happily continue to communicate > based on an authentication that was weeks or months in the past > and do not care at all the authentication cert may have long > expired or been revoked in the meantime. That's why draft-ietf-xmpp-3920bis-04 (section 14.2.2.3) talks about the need to (1) close the stream if the expiration date occurs during the life of the stream and (2) periodically check the OCSP responder. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070603020705040102000106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTEyMjE4MzgzNVowIwYJKoZIhvcNAQkEMRYEFLxEKdk7e/CrEymREUFS ZX1qtYc5MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAImoDRil8ok4RYcE3BbnIUGxpJOQsqJpUvcyGl0Vl LTN12+Gt3MTUOQtSjEst7LvjEzulMIp8TER5u01usqIjevOWKrixfZkk+kAyMPDsKLDw7LTw lYNMgnGB2OUA3pUJ3wQy7wgkK+3929ZhBOwBWktbt/xzO4i9Z1chSb9OaytgruX7Fd+wvmKS XI9EClOKBlXRub0gs9fNVeobp16kox/YBVbnidqRJOqt4U60upsgE+5uA39oq+VAtxeaTJbF uZ/yDDv80//sZK5SnUnDvUdaZKH6JUiTat8Op3SplTw/w1mBtJJvBlGBScSOULJF6EjOj/2o jGm/vTK24At4EwAAAAAAAA== --------------ms070603020705040102000106-- From benl@google.com Sun Nov 22 11:07:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EEA33A69DA for ; Sun, 22 Nov 2009 11:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 s-sW3mocr+fv for ; Sun, 22 Nov 2009 11:07:55 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id EC6803A692B for ; Sun, 22 Nov 2009 11:07:54 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id nAMJ7nso001723 for ; Sun, 22 Nov 2009 19:07:50 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258916870; bh=rSrJW4XqpHWbkGSOfWVM0bai1oQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=dD/ek7AokD+KDmqTgld+POxkGxTWxar1JjCiEi9gIA7XlzrfLC4Bl3D9XbfXurZfe 2jhLMwBCCtlbjTga64WVw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Lzw8iOljdNbFzxrV2uTWnks9SJ8hyX+vAkne8OmHV2kZQfARaOCIY1z5MsZ7N/lcC 7KXNndtPW64+R9y+JqMrA== Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by wpaz33.hot.corp.google.com with ESMTP id nAMJ7lSZ014797 for ; Sun, 22 Nov 2009 11:07:47 -0800 Received: by qyk10 with SMTP id 10so2562728qyk.12 for ; Sun, 22 Nov 2009 11:07:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.32.148 with SMTP id c20mr524088qcd.52.1258916866904; Sun, 22 Nov 2009 11:07:46 -0800 (PST) In-Reply-To: <4B086752.1030205@jacaranda.org> References: <4B06E2D7.2040302@jacaranda.org> <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> <4B086752.1030205@jacaranda.org> Date: Sun, 22 Nov 2009 11:07:46 -0800 Message-ID: <1b587cab0911221107u4ac1a854p235d493584d8296c@mail.gmail.com> From: Ben Laurie To: David-Sarah Hopwood Content-Type: multipart/alternative; boundary=0016364ed7d0a759bf0478fa6c0f X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 19:07:56 -0000 --0016364ed7d0a759bf0478fa6c0f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 21, 2009 at 2:18 PM, David-Sarah Hopwood < david-sarah@jacaranda.org> wrote: > Ben Laurie wrote: > > On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood < > > david-sarah@jacaranda.org> wrote: > > > >> Stefan Santesson wrote: > >>> On 09-11-20 5:24 AM, "Michael D'Errico" wrote: > >>> > >>>> Some servers apparently cannot function without renegotiation. > >>>> They will need to continue providing service to unpatched > >>>> clients for some amount of time and thus remain vulnerable. > >>> I fully agree, > >>> > >>> However, just because a server accepts renegotiation with an unpatche= d > >>> client, does not necessarily mean that the service provided over TLS = is > >>> vulnerable. > >>> > >>> One example is if authentication is performed with proper channel > binding > >>> in a layer above TLS and the service is provided under that security > >>> context. > >> > >> I'm skeptical. How can "proper channel binding" be done correctly in a > >> layer above TLS, if the TLS library merges renegotiated sessions? > >> Since the session merging will result in the client and server's state > >> at the higher layer(s) being out of sync, nothing can be assumed about > >> the correct functioning of those layers. > > > > The depends on those layers. If, for example, clients and servers simpl= y > > numbered their requests/responses, they would be immune to the attack. > > That's not sufficient. They'd also have to make sure that renegotiation > boundaries coincide with request/response boundaries. That requires that > the app be notified by the TLS library precisely when a renegotiation > occurs, and that individual reads and writes cannot extend across a > renegotiation boundary. This contradicts the assumption that I stated > explicitly above: "if the TLS library merges renegotiated sessions". > It's also rather prone to application error even in cases where it would > theoretically work. > I don't believe your argument. For example, if each byte were numbered, the= n the application would not care one whit about boundaries (other than reconnections, which it manages anyway). > > -- > David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --0016364ed7d0a759bf0478fa6c0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Nov 21, 2009 at 2:18 PM, David-S= arah Hopwood <david-sarah@jacaranda.org> wrote:
Ben Laurie wrote:
> On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood <
> david-sarah@jacaranda.org= > wrote:
>
>> Stefan Santesson wrote:
>>> On 09-11-20 5:24 AM, "Michael D'Errico" <mike-list@pobox.com> wrote:
>>>
>>>> Some servers apparently cannot function without renegotiat= ion.
>>>> They will need to continue providing service to unpatched<= br> >>>> clients for some amount of time and thus remain vulnerable= .
>>> I fully agree,
>>>
>>> However, just because a server accepts renegotiation with an u= npatched
>>> client, does not necessarily mean that the service provided ov= er TLS is
>>> vulnerable.
>>>
>>> One example is if authentication is performed with proper chan= nel binding
>>> in a layer above TLS and the service is provided under that se= curity
>>> context.
>>
>> I'm skeptical. How can "proper channel binding" be d= one correctly in a
>> layer above TLS, if the TLS library merges renegotiated sessions?<= br> >> Since the session merging will result in the client and server'= ;s state
>> at the higher layer(s) being out of sync, nothing can be assumed a= bout
>> the correct functioning of those layers.
>
> The depends on those layers. If, for example, clients and servers simp= ly
> numbered their requests/responses, they would be immune to the attack.=

That's not sufficient. They'd also have to make sure that ren= egotiation
boundaries coincide with request/response boundaries. That requires that the app be notified by the TLS library precisely when a renegotiation
occurs, and that individual reads and writes cannot extend across a
renegotiation boundary. This contradicts the assumption that I stated
explicitly above: "if the TLS library merges renegotiated sessions&quo= t;.
It's also rather prone to application error even in cases where it woul= d
theoretically work.

I don't believe your argum= ent. For example, if each byte were numbered, then the application would no= t care one whit about boundaries (other than reconnections, which it manage= s anyway).
=C2=A0

--
David-Sarah Hopwood =C2=A0=E2=9A= =A5 =C2=A0h= ttp://davidsarah.livejournal.com


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--0016364ed7d0a759bf0478fa6c0f-- From frantz@pwpconsult.com Sun Nov 22 11:49:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75CB3A68EF for ; Sun, 22 Nov 2009 11:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 v4lzMMtp8Hfa for ; Sun, 22 Nov 2009 11:49:15 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id F2B7D3A67D2 for ; Sun, 22 Nov 2009 11:49:14 -0800 (PST) Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NCIQo-0006bS-Pw; Sun, 22 Nov 2009 14:49:11 -0500 Date: Sun, 22 Nov 2009 11:49:24 -0800 From: Bill Frantz To: Yoav Nir X-Priority: 3 In-Reply-To: <8A7ED133-F3A2-4574-A49F-EB48393FA3C0@checkpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79b89df5923b11a2bd985dcfaa8c045eb1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.34 Cc: tls Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 19:49:16 -0000 ynir@checkpoint.com (Yoav Nir) on Sunday, November 22, 2009 wrote: >On Nov 22, 2009, at 3:11 AM, Michael Stone wrote: > > >>=20 >> Third, we believe the proposed solution of "upgrade all SSL3 clients to = TLS" >> to be unrealistic in general.=20 >>=20 >> That is, while "upgrade all SSL3 clients to TLS" may be good advice for >> browsers and for many other SSL3 clients on the public internet, we are >> sensitive to the enormous variety of circumstances in which SSL3 is depl= oyed >> and would be saddened to see the this working group leave behind end-use= rs who >> require renegotiation and who are unable to upgrade to TLS but who could >> nevertheless manage to apply a minimally invasive change to their legacy= SSL3 >> implementation.=20 > >Agree, but you can't change any client from vulnerable to not-vulnerable, = unless you do one of three things: > - implement the new binding (new Finished message) > - receive a signal that the gateway is patched, and won't renegotiate wit= h you, and failing that...=20 > - not connect to un-patched servers. Marsh Ray has referred to a possible defect where the MITM causes the client to renegotiate while the server does not. If I understand the situation correctly, for a client to be safe from this attack, the above would become: Agree, but you can't change any client from vulnerable to not-vulnerable, unless you do one of two things: - implement the new binding (new Finished message) in both directions. - receive a signal that the server is patched which means it won't renegot= iate with you, and not renegotiate with the server yourself. The client MUST NOT connect with a server unless one of these two conditions holds. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 From djhopwood@googlemail.com Sun Nov 22 13:16:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98E63A6821 for ; Sun, 22 Nov 2009 13:16:17 -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 MUAcRUV-L8Oj for ; Sun, 22 Nov 2009 13:16:16 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 6B4343A6951 for ; Sun, 22 Nov 2009 13:16:16 -0800 (PST) Received: by ewy6 with SMTP id 6so1302119ewy.29 for ; Sun, 22 Nov 2009 13:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=hr8e00t6GaITcgDhDnbbyhh8Ff3pxR/dY5XZkWzFGKE=; b=MbPdu4cjEWVPTwKXSTisisd7bwETrSXATGqqOrEV5NKHmK/2SOyahtrX0j0K8h4z6Q uUSnE5WbMl31IzNH5G+wd1eH3WIettBfCwc06ABBXc7x0a+7HTCaz0eu68GVeVsyx/oH +6ndO8H8PvdXm6tee/9dHYMPsk5fPQRcjKdkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=AtOPasyZ/z4WGigfPMBpWJAAXbVPHCLeIvpujZAY9teuOL5dQ1bLU8VHnZMr5ORAqf XwMFu8vn9hti0Vr13IQ+ZvipbNLD8cLrkAvaM8oBD3AgaXQ/Qg1o5Di+GJMv9YHPpvtm Dzv0T9IZjJBjwSgZKcuUN1EDKdzxeIuOhMYF8= Received: by 10.213.2.84 with SMTP id 20mr2758842ebi.90.1258924569756; Sun, 22 Nov 2009 13:16:09 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 5sm885271eyh.40.2009.11.22.13.16.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Nov 2009 13:16:08 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B09AA00.9040205@jacaranda.org> Date: Sun, 22 Nov 2009 21:15:44 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B06E2D7.2040302@jacaranda.org> <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> <4B086752.1030205@jacaranda.org> <1b587cab0911221107u4ac1a854p235d493584d8296c@mail.gmail.com> In-Reply-To: <1b587cab0911221107u4ac1a854p235d493584d8296c@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF3D4C758DA677365BCDEF372" Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 21:16:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF3D4C758DA677365BCDEF372 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ben Laurie wrote: > On Sat, Nov 21, 2009 at 2:18 PM, David-Sarah Hopwood < > david-sarah@jacaranda.org> wrote: >=20 >> Ben Laurie wrote: >>> On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood < >>> david-sarah@jacaranda.org> wrote: >>> >>>> Stefan Santesson wrote: >>>>> On 09-11-20 5:24 AM, "Michael D'Errico" wrote= : >>>>> >>>>>> Some servers apparently cannot function without renegotiation. >>>>>> They will need to continue providing service to unpatched >>>>>> clients for some amount of time and thus remain vulnerable. >>>>> I fully agree, >>>>> >>>>> However, just because a server accepts renegotiation with an unpatc= hed >>>>> client, does not necessarily mean that the service provided over TL= S is >>>>> vulnerable. >>>>> >>>>> One example is if authentication is performed with proper channel >>>>> binding in a layer above TLS and the service is provided under that= >>>>> security context. >>>> >>>> I'm skeptical. How can "proper channel binding" be done correctly in= a >>>> layer above TLS, if the TLS library merges renegotiated sessions? >>>> Since the session merging will result in the client and server's sta= te >>>> at the higher layer(s) being out of sync, nothing can be assumed abo= ut >>>> the correct functioning of those layers. >>> >>> The depends on those layers. If, for example, clients and servers sim= ply >>> numbered their requests/responses, they would be immune to the attack= =2E >> >> That's not sufficient. They'd also have to make sure that renegotiatio= n >> boundaries coincide with request/response boundaries. That requires th= at >> the app be notified by the TLS library precisely when a renegotiation >> occurs, and that individual reads and writes cannot extend across a >> renegotiation boundary. This contradicts the assumption that I stated >> explicitly above: "if the TLS library merges renegotiated sessions". >> It's also rather prone to application error even in cases where it wou= ld >> theoretically work. >=20 > I don't believe your argument. For example, if each byte were numbered,= then > the application would not care one whit about boundaries (other than > reconnections, which it manages anyway). Numbering each byte is not what you suggested above. You haven't given enough detail to tell whether this could work, but if for the sake of argument it could, it would require incompatible changes to the applicati= on protocol. Therefore, it's not an argument that justifies the original point by Stefan Santesson above, about servers that accept renegotiations= with unpatched clients not necessarily being vulnerable. In practice, suc= h servers will be vulnerable for existing protocols. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigF3D4C758DA677365BCDEF372 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksJqgsACgkQWUc8YzyzqAeljAEAhTsoaT4/TeEZlaL1IMzkj9yk sNOe4gpkXRlC0b2AOT8A/R6dIWSuqBeD9CVjyPEmmf5aymF9F88D2duwy/KLICBz =+2ec -----END PGP SIGNATURE----- --------------enigF3D4C758DA677365BCDEF372-- From djhopwood@googlemail.com Sun Nov 22 13:35:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4025B3A68F4 for ; Sun, 22 Nov 2009 13:35:36 -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 vtd+7-J7HvdQ for ; Sun, 22 Nov 2009 13:35:35 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id EC7853A6844 for ; Sun, 22 Nov 2009 13:35:34 -0800 (PST) Received: by ewy6 with SMTP id 6so1314229ewy.29 for ; Sun, 22 Nov 2009 13:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=wHcW18V6+ZCi28UzfD4uG3ldk1MrUvakHC6+0vzIQvA=; b=GF9heV89tc6tYAniJ4F1noXx6XA3E9JG65EGv/EMYW3pilCXeVzUk+ZqwMBxEFaLaV l7s9XZhGH0ULQPo1gnd6foe3/PuJehxzr4Culg1UbG6zlaz1tqfT+imwaJhpkKlJ+vbr kty9NZFQa4VoycXU+4pGHuhw0lEM+dePMy0Ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Z/g9OxdNOObvcE2iqOnC5FlOA6aPNniNpGTTH8F5q9R7tR0oywjjXMYe43I+23p7eQ 7S6TqnffPEaxbPb9bj9QTcJQI3e/1Rzr1eMHlcwcN1Oa/Dk7f8Kc8f5QgnjWzVmKYO25 AeLxt7eAhSwfptxWjZEFi91WqiKqg1nN2vlZ4= Received: by 10.213.96.83 with SMTP id g19mr3984327ebn.20.1258925727052; Sun, 22 Nov 2009 13:35:27 -0800 (PST) Received: from ?192.168.0.2? (5e023669.bb.sky.com [94.2.54.105]) by mx.google.com with ESMTPS id 23sm887764eya.43.2009.11.22.13.35.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Nov 2009 13:35:26 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B09AE89.3080107@jacaranda.org> Date: Sun, 22 Nov 2009 21:35:05 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig291BF390BFD3A532EF3EAB85" Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 21:35:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig291BF390BFD3A532EF3EAB85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bill Frantz wrote: > ynir@checkpoint.com (Yoav Nir) on Sunday, November 22, 2009 wrote: >> On Nov 22, 2009, at 3:11 AM, Michael Stone wrote: >> >> >>> Third, we believe the proposed solution of "upgrade all SSL3 clients = to TLS" >>> to be unrealistic in general.=20 >>> >>> That is, while "upgrade all SSL3 clients to TLS" may be good advice f= or >>> browsers and for many other SSL3 clients on the public internet, we a= re >>> sensitive to the enormous variety of circumstances in which SSL3 is d= eployed >>> and would be saddened to see the this working group leave behind end-= users who >>> require renegotiation and who are unable to upgrade to TLS but who co= uld >>> nevertheless manage to apply a minimally invasive change to their leg= acy SSL3 >>> implementation.=20 >> Agree, but you can't change any client from vulnerable to not-vulnerab= le, unless you do one of three things: >> - implement the new binding (new Finished message) >> - receive a signal that the gateway is patched, and won't renegotiate = with you, and failing that...=20 >> - not connect to un-patched servers. >=20 > Marsh Ray has referred to a possible defect where the MITM causes the > client to renegotiate while the server does not. If I understand the > situation correctly, for a client to be safe from this attack, the abov= e > would become: >=20 > Agree, but you can't change any client from vulnerable to not-vulnerabl= e, > unless you do one of two things: > - implement the new binding (new Finished message) in both directions.= > - receive a signal that the server is patched which means it won't ren= egotiate > with you, and not renegotiate with the server yourself. >=20 > The client MUST NOT connect with a server unless one of these two > conditions holds. As far as I'm aware, the variant of the attack Marsh Ray referred to is only relevant to connections where TLS-level client authentication (clien= t certificates or PSK) is used. That's because, in the conditions under whi= ch this variant will work, a more straightforward MITM attack not involving renegotiation could achieve the same effect when TLS-level client authentication is not used. So, if a patched client's policy is to allow initial handshakes to an unpatched server, it is not reducing security any further by allowing renegotiations with an unpatched server where the client is unauthenticat= ed at the TLS level, for both the original and renegotiated connections. I think. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig291BF390BFD3A532EF3EAB85 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksJrpEACgkQWUc8YzyzqAc3sAD/d+f2tXkK2LV2U4ZXvWOgb5bS VUMqdRltuwe83QrIlusA/3IrCfGHEI8xVu3GIpubvMH1adt3uMPxE1wWUAhh4elq =Ohjc -----END PGP SIGNATURE----- --------------enig291BF390BFD3A532EF3EAB85-- From nelson@bolyard.me Sun Nov 22 13:42:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7343A6920 for ; Sun, 22 Nov 2009 13:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, 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 Ic+vjKuLHQRY for ; Sun, 22 Nov 2009 13:42:22 -0800 (PST) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id 8FDF63A67DD for ; Sun, 22 Nov 2009 13:42:22 -0800 (PST) Received: (qmail 23069 invoked from network); 22 Nov 2009 21:42:13 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 22 Nov 2009 21:42:13 -0000 Message-ID: <4B09AFC0.3030009@bolyard.me> Date: Sun, 22 Nov 2009 13:40:16 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: "tls@ietf.org" References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> <4B059658.2010200@extendedsubset.com> <4B07EA2B.5040809@drh-consultancy.demon.co.uk> <4B08CCA3.3050104@bolyard.me> <4B09339D.7080108@drh-consultancy.demon.co.uk> In-Reply-To: <4B09339D.7080108@drh-consultancy.demon.co.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 21:42:23 -0000 On 2009-11-22 04:50 PST, Dr Stephen Henson wrote: > Nelson B Bolyard wrote: >> On 2009-11-21 05:24 PST, Dr Stephen Henson wrote: >> >>> Just to add a point to this which hasn't really been mentioned. >>> >>> The discussion of connection logic has largely been browser centric, >>> non-browser clients often work in a different way and the current >>> proposal (draft-ietf-tls-renegotiation-01.txt) can cause them >>> significant problems. >> >> Where is this draft? It's not on rfc-editor.org nor on ietf.org. Are >> you referring to draft-RESCORLA-tls-renegotiation-01.txt? >> > > Yes I meant the 01 version at: > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt That draft has been superseded. There has been a succession of 3 drafts: draft-RESCORLA-tls-renegotiation-00.txt draft-RESCORLA-tls-renegotiation-01.txt draft-IETF-tls-renegotiation-00.txt each of which superseded the previous. > Fallbacks aren't explicitly mentioned in the 00 draft. The whole issue of > how one can support secure renegotiation (if the server supports it) but > still connect to an unpatched SSLv3 or unpatched extension intolerant TLS > server isn't covered. Isn't it outside of scope? The draft named IETF (which I support with some minor clarifications) seems to address this quite directly. It says that secure renegotiation cannot be done with SSLv3. It talks about clients who want to take the risk may do it anyway. But clearly, doing so is outside of the scope and intent of this draft, which intent is to do things securely. > The 01 draft resolves this issue but requires fallbacks. > > It has been mentioned elsewhere that the obvious fallback techniques > using the 00 draft are vulnerable to downgrade attacks. If anyone has a > reference to a fallback technique that isn't vulnerable and complies to > the 00 draft I'd be interested to hear it. I believe that it is the intent of EKR's succession of drafts to NOT attempt to create an invulnerable form of SSLv3. Others in this list want to try to do that with alternative proposals. > Steve. From mrex@sap.com Sun Nov 22 13:54:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E843A67DD for ; Sun, 22 Nov 2009 13:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.134, 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 xGglGsZ5bbrY for ; Sun, 22 Nov 2009 13:54:53 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id B322F3A693D for ; Sun, 22 Nov 2009 13:54:52 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAMLsldH025506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Nov 2009 22:54:47 +0100 (MET) From: Martin Rex Message-Id: <200911222154.nAMLskLQ020410@fs4113.wdf.sap.corp> To: uri@ll.mit.edu (Blumenthal, Uri - 0662 - MITLL) Date: Sun, 22 Nov 2009 22:54:46 +0100 (MET) In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F3A@LLE2K7-BE01.mitll.ad.local> from "Blumenthal, Uri - 0662 - MITLL" at Nov 22, 9 08:43:45 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 21:54:53 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > > Sounds like a reasonable option. > > verify_data = > PRF(master_secret, finished_label, Hash(handshake_messages) > + previous_verify_data) > [0..verify_data_length-1]; I would definitely add it into Hash(handshake_messages) and following ServerHello, so that it gets automatically signed if client cert authentication is used without any further changes. > > > and I see no reason to exclude this option from consideration. Note that > > this would obviate any confusion about where the previous_verify_data > > goes in the handshake messages, or how it is encoded. More importantly, > > it guarantees that that the input to the PRF for the modified Finished > > computation cannot coincide with any possible input for the unmodified > > computation, which is a useful property that simplifies the security > > analysis. In the original TLS protocol, the verify_data from Client.Finished is added into Server.Finished as part of the Hash(handshake_messages). And that Server.Finished is what authenticates the entire TLS session including the Server (with its Certificate) to the client. So I don't think that making the Finished messages, which were the first data exchanged under the current TLS sessions, part of the Handshake message hash is a new concept that is completely new to TLS. -Martin From nelson@bolyard.me Sun Nov 22 14:00:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4F03A697B for ; Sun, 22 Nov 2009 14:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 mcidh8vfQpyG for ; Sun, 22 Nov 2009 14:00:06 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 70F8E3A6941 for ; Sun, 22 Nov 2009 14:00:06 -0800 (PST) Received: (qmail 20564 invoked from network); 22 Nov 2009 22:00:00 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 22 Nov 2009 21:59:59 -0000 Message-ID: <4B09B3EB.5020803@bolyard.me> Date: Sun, 22 Nov 2009 13:58:03 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911191921.nAJJLtwF007361@fs4113.wdf.sap.corp> <4B059FFC.1000903@extendedsubset.com> In-Reply-To: <4B059FFC.1000903@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 22:00:07 -0000 On 2009-11-19 11:43 PST, Marsh Ray wrote: > Martin Rex wrote: >> Of course, if vendors/suppliers are listening in to this discussion, >> it would be interesting to hear their opinion on what kind of changes >> might upset their equiment! > > I am a little disappointed that we don't get more input from vendors > discussing their real-world implementations. > > OpenSSL, Microsoft, Mozilla, and Opera seem to have been the best in > this regard. Just to clarify: I do not speak for Mozilla. I speak for NSS. NSS is an SSL/TLS library used by many companies' products, including Mozilla products, some server products from Sun Microsystems, and other products. Each of those product vendors is free to choose how they use NSS. NSS provides many configuration variables, and each product that uses it is free to use them as it wishes. The "fall back" logic about which so much discussion has taken place in this mailing list is not implemented in NSS. It is a part of the Mozilla browsers, outside (on top) of NSS. It exists solely because of servers that are intolerant of extensions (that refuse to negotiate a handshake if ANY extension is present), and because of broken old SSL 3.0 servers that cannot successfully negotiate SSL 3.0 when the client offers any other version. That fall back logic is now 11 years old. I think it has served its useful lifetime. I think the purveyors of those broken non-compliant old servers have had PLENTY of time to make their server correctly negotiate SSL 3.0 even when the client asks for TLS, and PLENTY of time to change to ignore all hello extensions. The browsers have not had a good reason to drop fall-back logic, until now. But now, the newly found vulnerability in those old servers is, IMO, reason enough for the browsers to disable that old fall back logic, and begin to require what (IMO) they should have required a decade ago, that servers actually do conform to the specifications to which they claim to conform, and CORRECTLY implement protocol version negotiation, and correctly ignore all non-recognized extensions. I am urging Mozilla to make that very change with all due haste. I think they have a pivotal decision to make. Is this vulnerability serious enough that it warrants cutting off those old servers that remain vulnerable to it? Or should they allow their users to continue to be vulnerable, by continuing to fully interoperate with those old vulnerable servers? That's their decision to make. I hope they will at least join the discussion pretty soon. From mrex@sap.com Sun Nov 22 14:21:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBDD3A6834 for ; Sun, 22 Nov 2009 14:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.132, 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 CnOkUqAheiho for ; Sun, 22 Nov 2009 14:21:57 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id DBDC93A67DD for ; Sun, 22 Nov 2009 14:21:56 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAMMLmoH010678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Nov 2009 23:21:48 +0100 (MET) From: Martin Rex Message-Id: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Sun, 22 Nov 2009 23:21:47 +0100 (MET) In-Reply-To: <4B09B3EB.5020803@bolyard.me> from "Nelson B Bolyard" at Nov 22, 9 01:58:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 22:21:58 -0000 Nelson B Bolyard wrote: > > That fall back logic is now 11 years old. I think it has served its useful > lifetime. I think the purveyors of those broken non-compliant old servers > have had PLENTY of time to make their server correctly negotiate SSL 3.0 > even when the client asks for TLS, and PLENTY of time to change to ignore > all hello extensions. I'm sorry, but I disagree. I would like to draw your attention to TLS v1.2 RFC-5246 Appendix E.1 & E.2 There is nothing in there that gives us any justification to kill extension-less SSLv3 ClientHellos or even SSLv2 ClientHellos now for any of the existing imlementations of TLSv1.0, TLSv1.1 and TLSv1.2. We may decide that for a future version of TLS, but not for any of the TLS Versions already shipped. Extension-less ClientHellos are neither root nor part of the vulnerability, we definitely do not need extensions to fix this protocol defect. It's our mess, so it is our task to clean it up. -Martin From benl@google.com Sun Nov 22 14:23:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1443A6897 for ; Sun, 22 Nov 2009 14:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 w4ZCoI6QnDT6 for ; Sun, 22 Nov 2009 14:23:09 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 4BA443A6857 for ; Sun, 22 Nov 2009 14:23:09 -0800 (PST) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id nAMMN5nL029148 for ; Sun, 22 Nov 2009 14:23:05 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258928585; bh=dzS5uK39NnXrbtZqUT2xpmIkBrU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kAjxuEi5dc39FP1/7XFXoreKW+UdMM6MG0WPBqf7YGXr2cJlFMTft4mtnF5iZtmkt KYSkr0gx105fTOwFqvO+w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=mj1d8awl2NtYTR3wPK7b/e/YqeAtoJy6rjxJI7LuAB0bBiIA2rWFMOfrhC7OrD8Aa pIDKT9BxeJ2dca5ikZK+g== Received: from qyk41 (qyk41.prod.google.com [10.241.83.169]) by zps76.corp.google.com with ESMTP id nAMMN1lr031009 for ; Sun, 22 Nov 2009 14:23:02 -0800 Received: by qyk41 with SMTP id 41so2632247qyk.29 for ; Sun, 22 Nov 2009 14:23:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.32.148 with SMTP id c20mr542265qcd.52.1258928581414; Sun, 22 Nov 2009 14:23:01 -0800 (PST) In-Reply-To: <4B09AA00.9040205@jacaranda.org> References: <4B06E2D7.2040302@jacaranda.org> <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com> <4B086752.1030205@jacaranda.org> <1b587cab0911221107u4ac1a854p235d493584d8296c@mail.gmail.com> <4B09AA00.9040205@jacaranda.org> Date: Sun, 22 Nov 2009 14:23:01 -0800 Message-ID: <1b587cab0911221423p32a22c44j546cffa2c32cfdeb@mail.gmail.com> From: Ben Laurie To: David-Sarah Hopwood Content-Type: multipart/alternative; boundary=0016364ed7d0e48e4b0478fd267a X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 22:23:10 -0000 --0016364ed7d0e48e4b0478fd267a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 22, 2009 at 1:15 PM, David-Sarah Hopwood < david-sarah@jacaranda.org> wrote: > Ben Laurie wrote: > > On Sat, Nov 21, 2009 at 2:18 PM, David-Sarah Hopwood < > > david-sarah@jacaranda.org> wrote: > > > >> Ben Laurie wrote: > >>> On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood < > >>> david-sarah@jacaranda.org> wrote: > >>> > >>>> Stefan Santesson wrote: > >>>>> On 09-11-20 5:24 AM, "Michael D'Errico" wrote= : > >>>>> > >>>>>> Some servers apparently cannot function without renegotiation. > >>>>>> They will need to continue providing service to unpatched > >>>>>> clients for some amount of time and thus remain vulnerable. > >>>>> I fully agree, > >>>>> > >>>>> However, just because a server accepts renegotiation with an > unpatched > >>>>> client, does not necessarily mean that the service provided over TL= S > is > >>>>> vulnerable. > >>>>> > >>>>> One example is if authentication is performed with proper channel > >>>>> binding in a layer above TLS and the service is provided under that > >>>>> security context. > >>>> > >>>> I'm skeptical. How can "proper channel binding" be done correctly in= a > >>>> layer above TLS, if the TLS library merges renegotiated sessions? > >>>> Since the session merging will result in the client and server's sta= te > >>>> at the higher layer(s) being out of sync, nothing can be assumed abo= ut > >>>> the correct functioning of those layers. > >>> > >>> The depends on those layers. If, for example, clients and servers > simply > >>> numbered their requests/responses, they would be immune to the attack= . > >> > >> That's not sufficient. They'd also have to make sure that renegotiatio= n > >> boundaries coincide with request/response boundaries. That requires th= at > >> the app be notified by the TLS library precisely when a renegotiation > >> occurs, and that individual reads and writes cannot extend across a > >> renegotiation boundary. This contradicts the assumption that I stated > >> explicitly above: "if the TLS library merges renegotiated sessions". > >> It's also rather prone to application error even in cases where it wou= ld > >> theoretically work. > > > > I don't believe your argument. For example, if each byte were numbered, > then > > the application would not care one whit about boundaries (other than > > reconnections, which it manages anyway). > > Numbering each byte is not what you suggested above. You haven't given > enough detail to tell whether this could work, but if for the sake of > argument it could, it would require incompatible changes to the applicati= on > protocol. Therefore, it's not an argument that justifies the original > point by Stefan Santesson above, about servers that accept renegotiations > with unpatched clients not necessarily being vulnerable. In practice, suc= h > servers will be vulnerable for existing protocols. > I agree. I was disputing that this was not fixable at the application layer= . > > -- > David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --0016364ed7d0e48e4b0478fd267a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 22, 2009 at 1:15 PM, David-S= arah Hopwood <david-sarah@jacaranda.org> wrote:
Ben Laurie wrote:
> On Sat, Nov 21, 2009 at 2:18 PM, David-Sarah Hopwood <
> david-sarah@jacaranda.org= > wrote:
>
>> Ben Laurie wrote:
>>> On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood <
>>> david-sarah@jacar= anda.org> wrote:
>>>
>>>> Stefan Santesson wrote:
>>>>> On 09-11-20 5:24 AM, "Michael D'Errico" = <mike-list@pobox.com> wrot= e:
>>>>>
>>>>>> Some servers apparently cannot function without re= negotiation.
>>>>>> They will need to continue providing service to un= patched
>>>>>> clients for some amount of time and thus remain vu= lnerable.
>>>>> I fully agree,
>>>>>
>>>>> However, just because a server accepts renegotiation w= ith an unpatched
>>>>> client, does not necessarily mean that the service pro= vided over TLS is
>>>>> vulnerable.
>>>>>
>>>>> One example is if authentication is performed with pro= per channel
>>>>> binding in a layer above TLS and the service is provid= ed under that
>>>>> security context.
>>>>
>>>> I'm skeptical. How can "proper channel binding&qu= ot; be done correctly in a
>>>> layer above TLS, if the TLS library merges renegotiated se= ssions?
>>>> Since the session merging will result in the client and se= rver's state
>>>> at the higher layer(s) being out of sync, nothing can be a= ssumed about
>>>> the correct functioning of those layers.
>>>
>>> The depends on those layers. If, for example, clients and serv= ers simply
>>> numbered their requests/responses, they would be immune to the= attack.
>>
>> That's not sufficient. They'd also have to make sure that = renegotiation
>> boundaries coincide with request/response boundaries. That require= s that
>> the app be notified by the TLS library precisely when a renegotiat= ion
>> occurs, and that individual reads and writes cannot extend across = a
>> renegotiation boundary. This contradicts the assumption that I sta= ted
>> explicitly above: "if the TLS library merges renegotiated ses= sions".
>> It's also rather prone to application error even in cases wher= e it would
>> theoretically work.
>
> I don't believe your argument. For example, if each byte were numb= ered, then
> the application would not care one whit about boundaries (other than > reconnections, which it manages anyway).

Numbering each byte is not what you suggested above. You haven&= #39;t given
enough detail to tell whether this could work, but if for the sake of
argument it could, it would require incompatible changes to the application=
protocol. Therefore, it's not an argument that justifies the original point by Stefan Santesson above, about servers that accept renegotiations with unpatched clients not necessarily being vulnerable. In practice, such<= br> servers will be vulnerable for existing protocols.
I agree. I was disputing that this was not fixable at the application laye= r.
=C2=A0

--
David-Sarah Hopwood =C2=A0=E2=9A= =A5 =C2=A0h= ttp://davidsarah.livejournal.com


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--0016364ed7d0e48e4b0478fd267a-- From lists@drh-consultancy.demon.co.uk Sun Nov 22 15:05:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBCE3A689F for ; Sun, 22 Nov 2009 15:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 AtlFq8luRa+6 for ; Sun, 22 Nov 2009 15:05:50 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by core3.amsl.com (Postfix) with ESMTP id 2E04F3A6938 for ; Sun, 22 Nov 2009 15:05:49 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49480 helo=[192.168.7.8]) by relay01.mail.eu.clara.net (relay.clara.net [213.253.3.41]:10587) with esmtpa (authdaemon_plain:drh) id 1NCLV1-00089K-5z (Exim 4.69) for tls@ietf.org (return-path ); Sun, 22 Nov 2009 23:05:44 +0000 Message-ID: <4B09C3C7.7000602@drh-consultancy.demon.co.uk> Date: Sun, 22 Nov 2009 23:05:43 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> <4B059658.2010200@extendedsubset.com> <4B07EA2B.5040809@drh-consultancy.demon.co.uk> <4B08CCA3.3050104@bolyard.me> <4B09339D.7080108@drh-consultancy.demon.co.uk> <4B09AFC0.3030009@bolyard.me> In-Reply-To: <4B09AFC0.3030009@bolyard.me> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 23:05:51 -0000 Nelson B Bolyard wrote: > On 2009-11-22 04:50 PST, Dr Stephen Henson wrote: > >> Fallbacks aren't explicitly mentioned in the 00 draft. The whole issue of >> how one can support secure renegotiation (if the server supports it) but >> still connect to an unpatched SSLv3 or unpatched extension intolerant TLS >> server isn't covered. > > Isn't it outside of scope? > > The draft named IETF (which I support with some minor clarifications) seems > to address this quite directly. It says that secure renegotiation cannot > be done with SSLv3. It talks about clients who want to take the risk may > do it anyway. But clearly, doing so is outside of the scope and intent of > this draft, which intent is to do things securely. > >> The 01 draft resolves this issue but requires fallbacks. >> >> It has been mentioned elsewhere that the obvious fallback techniques >> using the 00 draft are vulnerable to downgrade attacks. If anyone has a >> reference to a fallback technique that isn't vulnerable and complies to >> the 00 draft I'd be interested to hear it. > > I believe that it is the intent of EKR's succession of drafts to NOT attempt > to create an invulnerable form of SSLv3. Others in this list want to try to > do that with alternative proposals. > That is not my point. I'm not too bothered whether an invulnerable SSLv3 is ever created. I'd love it if extension intolerant servers vanished but I have to recognise that isn't going to happen in the short term. If you want to communicate with them it becomes necessary to perform secure renegotiation *if possible* but (at least for the present) tolerate unpatched extension intolerant servers. Similarly servers will have to tolerate unpatched clients for a while too. The problem with the draft as it stands is that AFAICS there is no way to tell the difference between an extension intolerant server and a MITM spoofing one with a patched server. This gives the client the difficult choice of either never talking to extension intolerant servers or being vulnerable to a downgrade attack. I find that choice unacceptable when alternative suggestions do not have that limitation. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From ekr@networkresonance.com Sun Nov 22 17:13:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14E13A68BC for ; Sun, 22 Nov 2009 17:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.258 X-Spam-Level: * X-Spam-Status: No, score=1.258 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_LWSHORTT=1.24] 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 L6HLocobezwr for ; Sun, 22 Nov 2009 17:13:09 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id C25A23A6860 for ; Sun, 22 Nov 2009 17:13:09 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id AACDC6C27BA; Sun, 22 Nov 2009 17:13:22 -0800 (PST) Date: Sun, 22 Nov 2009 17:13:22 -0800 From: Eric Rescorla To: Dr Stephen Henson In-Reply-To: <4B09C3C7.7000602@drh-consultancy.demon.co.uk> References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> <4B059658.2010200@extendedsubset.com> <4B07EA2B.5040809@drh-consultancy.demon.co.uk> <4B08CCA3.3050104@bolyard.me> <4B09339D.7080108@drh-consultancy.demon.co.uk> <4B09AFC0.3030009@bolyard.me> <4B09C3C7.7000602@drh-consultancy.demon.co.uk> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091123011322.AACDC6C27BA@kilo.networkresonance.com> Cc: "tls@ietf.org" Subject: Re: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 01:13:11 -0000 At Sun, 22 Nov 2009 23:05:43 +0000, Dr Stephen Henson wrote: > > Nelson B Bolyard wrote: > > On 2009-11-22 04:50 PST, Dr Stephen Henson wrote: > > > >> Fallbacks aren't explicitly mentioned in the 00 draft. The whole issue of > >> how one can support secure renegotiation (if the server supports it) but > >> still connect to an unpatched SSLv3 or unpatched extension intolerant TLS > >> server isn't covered. > > > > Isn't it outside of scope? > > > > The draft named IETF (which I support with some minor clarifications) seems > > to address this quite directly. It says that secure renegotiation cannot > > be done with SSLv3. It talks about clients who want to take the risk may > > do it anyway. But clearly, doing so is outside of the scope and intent of > > this draft, which intent is to do things securely. > > > >> The 01 draft resolves this issue but requires fallbacks. > >> > >> It has been mentioned elsewhere that the obvious fallback techniques > >> using the 00 draft are vulnerable to downgrade attacks. If anyone has a > >> reference to a fallback technique that isn't vulnerable and complies to > >> the 00 draft I'd be interested to hear it. > > > > I believe that it is the intent of EKR's succession of drafts to NOT attempt > > to create an invulnerable form of SSLv3. Others in this list want to try to > > do that with alternative proposals. > > > > That is not my point. I'm not too bothered whether an invulnerable SSLv3 is ever > created. > > I'd love it if extension intolerant servers vanished but I have to recognise > that isn't going to happen in the short term. > > If you want to communicate with them it becomes necessary to perform secure > renegotiation *if possible* but (at least for the present) tolerate unpatched > extension intolerant servers. Similarly servers will have to tolerate unpatched > clients for a while too. > > The problem with the draft as it stands is that AFAICS there is no way to tell > the difference between an extension intolerant server and a MITM spoofing one > with a patched server. > > This gives the client the difficult choice of either never talking to extension > intolerant servers or being vulnerable to a downgrade attack. I find that choice > unacceptable when alternative suggestions do not have that limitation. Hmm... Section 4.1.1 is intended to provide precisely that feature. In what way doesn't it work? -Ekr From lists@drh-consultancy.demon.co.uk Sun Nov 22 17:31:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956923A6985 for ; Sun, 22 Nov 2009 17:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 wR2RM4KxgdgB for ; Sun, 22 Nov 2009 17:31:25 -0800 (PST) Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by core3.amsl.com (Postfix) with ESMTP id 631D83A6782 for ; Sun, 22 Nov 2009 17:31:25 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50636 helo=[192.168.7.8]) by relay06.mail.eu.clara.net (relay.clara.net [213.253.3.46]:10587) with esmtpa (authdaemon_plain:drh) id 1NCNlu-0005Lz-LB (Exim 4.69) (return-path ); Mon, 23 Nov 2009 01:31:19 +0000 Message-ID: <4B09E5E5.7060606@drh-consultancy.demon.co.uk> Date: Mon, 23 Nov 2009 01:31:17 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <4B04F92A.8050903@extendedsubset.com> <4B053CF5.7000105@drh-consultancy.demon.co.uk> <4B059658.2010200@extendedsubset.com> <4B07EA2B.5040809@drh-consultancy.demon.co.uk> <4B08CCA3.3050104@bolyard.me> <4B09339D.7080108@drh-consultancy.demon.co.uk> <4B09AFC0.3030009@bolyard.me> <4B09C3C7.7000602@drh-consultancy.demon.co.uk> <20091123011322.AACDC6C27BA@kilo.networkresonance.com> In-Reply-To: <20091123011322.AACDC6C27BA@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 01:31:26 -0000 Eric Rescorla wrote: > At Sun, 22 Nov 2009 23:05:43 +0000, > Dr Stephen Henson wrote: >> >> This gives the client the difficult choice of either never talking to extension >> intolerant servers or being vulnerable to a downgrade attack. I find that choice >> unacceptable when alternative suggestions do not have that limitation. > > Hmm... Section 4.1.1 is intended to provide precisely that feature. > In what way doesn't it work? > Argh! I'd been referring to the wrong draft, sigh it's been a long day. I'll review that when I'm more awake. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nelson@bolyard.me Sun Nov 22 18:00:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6083A68C6 for ; Sun, 22 Nov 2009 18:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 WNKARDCtmC4A for ; Sun, 22 Nov 2009 18:00:41 -0800 (PST) Received: from p3plsmtpa01-08.prod.phx3.secureserver.net (p3plsmtpa01-08.prod.phx3.secureserver.net [72.167.82.88]) by core3.amsl.com (Postfix) with SMTP id 7D2FB3A672F for ; Sun, 22 Nov 2009 18:00:41 -0800 (PST) Received: (qmail 24372 invoked from network); 23 Nov 2009 02:00:36 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 23 Nov 2009 02:00:36 -0000 Message-ID: <4B09ECAB.7050205@bolyard.me> Date: Sun, 22 Nov 2009 18:00:11 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> In-Reply-To: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 02:00:42 -0000 On 2009-11-22 14:21 PST, Martin Rex wrote: > Nelson B Bolyard wrote: >> That fall back logic is now 11 years old. I think it has served its >> useful lifetime. I think the purveyors of those broken non-compliant >> old servers have had PLENTY of time to make their server correctly >> negotiate SSL 3.0 even when the client asks for TLS, and PLENTY of time >> to change to ignore all hello extensions. > > I'm sorry, but I disagree. > > I would like to draw your attention to TLS v1.2 RFC-5246 Appendix E.1 & > E.2 If I may summarize it, it says that, because all versions of the TLS specification have always required that unrecognized extensions be ignored, TLS 1.2 client may send extensions to older TLS servers without worry about new extensions. Protocol version negotiation will take care of the rest. That also applies to specification compliant SSL 3.0 servers, which were always supposed to ignore extra data in the client hellos. > There is nothing in there that gives us any justification to kill > extension-less SSLv3 ClientHellos or even SSLv2 ClientHellos now for any > of the existing imlementations of TLSv1.0, TLSv1.1 and TLSv1.2. > Extension-less ClientHellos are neither root nor part of the > vulnerability, we definitely do not need extensions to fix this protocol > defect. > > It's our mess, so it is our task to clean it up. It is the duty of the TLS working group to fix the renegotiation vulnerability for clients and servers that are already compliant to any of the existing published RFCs for versions of TLS, and for any future implementations that will be compliant. Some in this list seem to demand that we also must devise a solution for servers that never did comply to any of the specifications for any of the versions, not even SSL 3.0, in that they did not ignore unknown hello extensions, and/or did not properly negotiate any version of SSL/TLS in the presence of requested versions other than 3.0. Even now, we are hearing requests from purveyors of non-compliant implementations who wish to remain non-compliant, but wish us to ensure that we will henceforth define TLS standards to ensure interoperability with their non-compliant implementations. The failures of non-compliant implementations to interoperate with compliant TLS implementations is not a shortcoming of the IETF TLS working group. It is not "bad engineering" on the part of the IETF TLS working group. The fact that some refuse to comply even now does not, IMO, create a burden of duty on the IETF TLS working group to devise solutions that can be implemented without requiring compliance in the implementations. As a standards body, we can only provide assurances of interoperability for implementations that comply to the specifications that we provide. It is not our duty nor our goal to provide guarantees of interoperability to those implementations that have avoided compliance for over a decade. From peter.robinson@rsa.com Sun Nov 22 18:11:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0903A68C6 for ; Sun, 22 Nov 2009 18:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 xloNTELU5vTD for ; Sun, 22 Nov 2009 18:10:54 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 729CA3A6927 for ; Sun, 22 Nov 2009 18:10:54 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nAN2Amvc027066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Nov 2009 21:10:48 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Sun, 22 Nov 2009 21:10:45 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2mp) with ESMTP id nAN2Ajot010520; Sun, 22 Nov 2009 21:10:45 -0500 Received: from CORPUSMX100B.corp.emc.com ([128.222.76.52]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 21:10:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Nov 2009 21:10:43 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_1A68_01CA6C35.FAFB4C40" Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: AcpqK+P+FJb7/ERHTaOcgXqgj6VcUgBtiMxA References: From: To: , X-OriginalArrivalTime: 23 Nov 2009 02:10:45.0294 (UTC) FILETIME=[2A7A9CE0:01CA6BE2] X-EMM-EM: Active Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 02:11:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1A68_01CA6C35.FAFB4C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support this draft. ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey (jsalowey) Sent: Saturday, 21 November 2009 7:53 AM To: tls@ietf.org Subject: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt We have had a lot of good discussion on this list, but I think we need to start converging on a solution. As I said in a previous message, I've asked Eric to serve as editor for the WG draft and he has posted draft-ietf-tls-renegotiation-00 as a starting point. I realize that there are a number of people who aren't happy with aspects of the draft, or indeed with the draft as a whole, but I'd like to get the sense for the feelings of the group as a whole. If we have rough consensus that this is a workable approach, we can try to nail down the remaining issues and move forward. To try to keep this concrete, please respond with answers to this question: Support for the draft: - I support this draft - I support this draft with the following modification - I would support an entirely different proposal (please identify it; be specific) If you are proposing a modification, in addition to providing a description and rationale for a modification to the document it is helpful to provide sample text of the modification. Also, please indicate whether you would only support the draft with your modification or whether you can live with it unmodified. Thanks, Joe _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_1A68_01CA6C35.FAFB4C40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWmzCCAucw ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1 s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5 IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3 Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/ eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5 /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1 cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13 qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggR+MIID56ADAgECAhEAsSe9 yNTH2rYKRiN7F8KhkTANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT MB4XDTA5MDcyMTA1MTYxM1oXDTExMDcyMjA1MTYxM1owgekxEzARBgoJkiaJk/IsZAEZFgNjb20x EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjEMMAoGA1UECxMD UlNBMRUwEwYDVQQLEwxBc2lhL1BhY2lmaWMxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQF EwYwNjQ4MTQxFzAVBgoJkiaJk/IsZAEBEwdyb2JpbnAyMRcwFQYDVQQDEw5QZXRlciBSb2JpbnNv bjElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA2CcjIV2QNoJP4YbPejhZX2MSu53/EooTnrkf7M4gsl1DobXkk3CO6kU9bN6O wwL/o87dQ4y2FHjwkV4WeoodhvZa08q5uX4vZCtB2Hn0OUrbPzyKl7wXSq+yezKCQJBrVCTwWjKK A6Gqc1VhkqWSBCpUaQ39TsVDxNYCGIn433cCAwEAAaOCAX8wggF7MIGSBgNVHSAEgYowgYcwgYQG CSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5o dG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9y YXRlZCBieSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnBldGVyLnJvYmluc29uQHJzYS5jb20wDgYDVR0PAQH/BAQDAgeAMEYG A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQm 7p962rS9dUpGeQZt+Vi1su6tQTANBgkqhkiG9w0BAQUFAAOBgQCghPP5wxcDJuACPYJ/U1sjhyE4 gxpGKZNPnnDcjfHo+Cq87cWawpV5Rzpg8KVZc0EoG6BabGNyk+WgZMjCzADpg+appN4cX+DML0ir 3cBcX8pQTuKw1VRlUjidjkTIl/Z2hrcvgh2lJG+PFV2ogWICzwOj4/zKG4khs9VO5NNPezCCBI4w ggP3oAMCAQICEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFS U0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xh c3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czELMAkGA1UEBhMCVVMwHhcNMDkwNzIxMDUxNjE4WhcNMTEwNzIyMDUxMzM2WjCB7TETMBEGCgmS JomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0 aW9uMQwwCgYDVQQLEwNSU0ExFTATBgNVBAsTDEFzaWEvUGFjaWZpYzEUMBIGA1UECxMLRW5naW5l ZXJpbmcxDzANBgNVBAUTBjA2NDgxNDEXMBUGCgmSJomT8ixkAQETB3JvYmlucDIxGzAZBgNVBAMT ElBldGVyIFJvYmluc29uLUVuYzElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqeM4888BmvaveugOJqTYWGNm3cTP6qJe444S 7AJaXDnKZlt1cJByB+B83hdGGe2FyRQGGef0DNZhQIfaa41dzZbDWuogZ3mKxyuOhciZSoRoCIM0 jlPh5vqhDmXBPFQ/EedNPRk+tl+mKVz2fHbsI01bWtueV05BvJu330cj0WUCAwEAAaOCAYswggGH MDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDCB kgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwUwdzAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNl Y3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMC AQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCEGA1UdEQQaMBiBFnBldGVyLnJvYmlu c29uQHJzYS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206 ODAvUlNBQ2xhc3MyUGVyc29uYWxDQS5jcmwwHwYDVR0jBBgwFoAUxpPuxqX+41WOz4ojH+6Y3iHy n6cwHQYDVR0OBBYEFGg/pAQlQSo2dvZeyryhS2toL395MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG 9w0BAQUFAAOBgQCY/nGMkd29x8wULeVsTP+emR/XVn+LqcfwzgwpUSKP1FX1WedrHwlNKFaVDjQX FaNETkV4XzMugf4iafsgZUp5DmzIOBB5H5MI1k+CprZ0tjet7gcN0sdCt0fggfw44GZ37rwxzwyt XZrbEePtb8wFYVEobKBD/ZqvghavL93K3DGCA4EwggN9AgEBMIGiMIGMMRowGAYDVQQKExFSU0Eg U2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3Mg MiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEL MAkGA1UEBhMCVVMCEQCxJ73I1MfatgpGI3sXwqGRMAkGBSsOAwIaBQCgggI0MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTEyMzAyMTA0M1owIwYJKoZIhvcNAQkE MRYEFOF0kHzh3bpT8wP9rXzPLq8LJmoVMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA UZpCkHzuqduLehX5dEK9DCBVcDcL1dvXi2kvCpI0/qo2ljS6pHiJZhsIPHz88JjxsAjtxggNEO8G gftctni3Mgklel+Gwq5q6jR4drAXA6diAnu1sZnQOotNKsLzFHGLom7BKfBFjd3M6zzFnKojlBuA j1WOPKzILD46iJgrT2gAAAAAAAA= ------=_NextPart_000_1A68_01CA6C35.FAFB4C40-- From mike-list@pobox.com Sun Nov 22 18:28:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485773A69F4 for ; Sun, 22 Nov 2009 18:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 xoJx8mQt5NVQ for ; Sun, 22 Nov 2009 18:28:53 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 9CA933A6989 for ; Sun, 22 Nov 2009 18:28:52 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 13970821B4 for ; Sun, 22 Nov 2009 21:28:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=NCE7sY8nNapx xTx1tLQT20yI/ro=; b=sWPoUHAP6LsS0/m6QR9Ila/9/W3sCBh+wm0HBIzAyD9C /8+yI2UwlMI87UMXMEv6P+lL9ENk6rqG8iYoREWtDK8o81Rn5yrizPHNeSGluQus c3jguIhVMowi21Xr0fNDo1eyOfpqwnC7u83YbdJmOXpdhgBAbvQcmNhF2aKQivY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=wjqEbO 7GMSrhCUchZFcp6Dey0CjXvYg2Zo9tQCmKGqCTyMmg2gbV6dWGEgKhC8e6m4uU2r jCcpnBNZIecNKQQ2Hz4xiPSWwfQeo+Og+yDhqFtkBeqobMpdzCrZExthImt8fPcd v7H4H3sPNRiNGbiqmAD1YdQ2QRTWsifBpzhfI= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0E299821B3 for ; Sun, 22 Nov 2009 21:28:48 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 94311821B2 for ; Sun, 22 Nov 2009 21:28:47 -0500 (EST) Message-ID: <4B09F3C0.9060704@pobox.com> Date: Sun, 22 Nov 2009 18:30:24 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> In-Reply-To: <4B09ECAB.7050205@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: EE199460-D7D7-11DE-95BB-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 02:28:55 -0000 If you take an elitist position like the one you seem to be advocating, you run the risk that your "pure" standard-compliant fix will be ignored and people will come up with their own solutions. You will quickly become irrelevant. If you were to ask me my opinion of what I would _like_ to be true, it would be a rosy world where all standards are implemented correctly and everybody's code interops with everybody else's. But the reality is old code takes a long time to die. That's why there is a thing called "maintenance." You might like to think that you can force all of this old code to get upgraded, but that's not going to happen. It needs to be _patched_! Mike Nelson B Bolyard wrote: > > It is the duty of the TLS working group to fix the renegotiation > vulnerability for clients and servers that are already compliant to any of > the existing published RFCs for versions of TLS, and for any future > implementations that will be compliant. > > Some in this list seem to demand that we also must devise a solution for > servers that never did comply to any of the specifications for any of the > versions, not even SSL 3.0, in that they did not ignore unknown hello > extensions, and/or did not properly negotiate any version of SSL/TLS in the > presence of requested versions other than 3.0. > > Even now, we are hearing requests from purveyors of non-compliant > implementations who wish to remain non-compliant, but wish us to ensure > that we will henceforth define TLS standards to ensure interoperability with > their non-compliant implementations. > > The failures of non-compliant implementations to interoperate with compliant > TLS implementations is not a shortcoming of the IETF TLS working group. It > is not "bad engineering" on the part of the IETF TLS working group. The > fact that some refuse to comply even now does not, IMO, create > a burden of duty on the IETF TLS working group to devise solutions that > can be implemented without requiring compliance in the implementations. > > As a standards body, we can only provide assurances of interoperability for > implementations that comply to the specifications that we provide. It is > not our duty nor our goal to provide guarantees of interoperability to > those implementations that have avoided compliance for over a decade. From mrex@sap.com Sun Nov 22 19:06:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210FF3A68DB for ; Sun, 22 Nov 2009 19:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=0.131, 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 vOBCfDzRLnet for ; Sun, 22 Nov 2009 19:06:14 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 023FA3A67BE for ; Sun, 22 Nov 2009 19:06:13 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAN366Kb002559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 04:06:06 +0100 (MET) From: Martin Rex Message-Id: <200911230306.nAN365xl020466@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Mon, 23 Nov 2009 04:06:05 +0100 (MET) In-Reply-To: <4B09ECAB.7050205@bolyard.me> from "Nelson B Bolyard" at Nov 22, 9 06:00:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 03:06:15 -0000 Nelson B Bolyard wrote: > > > > I would like to draw your attention to TLS v1.2 RFC-5246 Appendix E.1 & > > E.2 > > If I may summarize it, it says that, because all versions of the TLS > specification have always required that unrecognized extensions be ignored, > TLS 1.2 client may send extensions to older TLS servers without worry about > new extensions. Protocol version negotiation will take care of the rest. I read something else in that sections. These sections describes known problems with the installed bases of servers and gives recommendations to _compliant_ clients in order to retain interoperability. It is the golden rule of the IETF "be liberal in what you accept, be conservative in what you send out" which means that in order to achieve interoperability, _compliant_ clients should be conservative in what they send out, they may want to choose an extenion-less SSLv3 ClientHello or maybe even an old SSLv2 ClientHello if they do not have an app-level fallback reconnect mechanism to followup on a failed ClientHello with TLS extensions. If TLS WG ignores the existence and the necessity of such fallback re-connects, which are perfectly within the TLSv1.2 spec: Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client. the a solution that does not work for those fallbacks will turn these app-level fallbacks into downgrade security vulnerabilities. Personally, I do not think that creating security vulnerabilities on purpose is a good idea. If Appendix E of rfc-5246 would contain only this one sentence: Compliant TLS clients MUST NOT send extension-less ClientHello handshake messages. then you might argue that for TLSv1.2 you can ignore this problem. But TLSv1.2 actually amounts to "MAY send extension-less ClientHello" and btw. we actually need to fix an installed base of TLSv1.1 and TLSv1.0 and SSLv3. No matter how you look at it. Sending an extension-less ClientHello is not a security problem. Fixing the renegotiation vulnerability in a fashion that turns perfectly spec-compliant behaviour into a security vulnerability is a security problem in that fix. I do not think it is a good idea to replace a large security problem with a medium security problem just because a thorough fix appears "slightly unaesthetical". -Martin From nelson@bolyard.me Sun Nov 22 19:07:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCFA3A67BE for ; Sun, 22 Nov 2009 19:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 nNjCNH-Zw5pQ for ; Sun, 22 Nov 2009 19:07:12 -0800 (PST) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by core3.amsl.com (Postfix) with SMTP id 359733A67B2 for ; Sun, 22 Nov 2009 19:07:12 -0800 (PST) Received: (qmail 23898 invoked from network); 23 Nov 2009 03:07:03 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 23 Nov 2009 03:07:03 -0000 Message-ID: <4B09FC30.4070107@bolyard.me> Date: Sun, 22 Nov 2009 19:06:24 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> In-Reply-To: <4B09F3C0.9060704@pobox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 03:07:13 -0000 On 2009-11-22 18:30 PST, Michael D'Errico wrote: > If you take an elitist position like the one you seem to be advocating, > you run the risk that your "pure" standard-compliant fix will be ignored > and people will come up with their own solutions. You will quickly > become irrelevant. The purveyors of all those old non-compliant products are desperately afraid that the browsers will unify and decide as a group to stop supporting fall-back for extension intolerant servers. Then those old servers would quickly become irrelevant. > But the reality is old code takes a long time to die. That's why there > is a thing called "maintenance." You might like to think that you can > force all of this old code to get upgraded, but that's not going to > happen. It needs to be _patched_! And the very first patch it needs to to finally comply with the 13 year old specification that requires it to ignore unknown extensions. That's not an upgrade. From mike-list@pobox.com Sun Nov 22 19:37:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91FF3A6896 for ; Sun, 22 Nov 2009 19:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 APm8j-wyNEdb for ; Sun, 22 Nov 2009 19:37:14 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 21CA83A6861 for ; Sun, 22 Nov 2009 19:37:12 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 51C47A0A81 for ; Sun, 22 Nov 2009 22:37:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=ajOenvOYG4e6 m2nfRmTscAqzphk=; b=iHUjEGdl2ohzwmH9J5A16GAYw+rxPzwV4uEIJDD/TdJg 3qWhONJeG8VhDW7HN2JuD3U+5dmeJflD0jYBCGPCo9VtuzJBIw7FWfspQNCEs5CN 3ru2iJ0Kx/vuYluk8sPpkmMuj6y9HVDfGnv/y3ZLjhyduGYalearTpHmb8955iE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=J2HoMo V9DpzuOnIuMiqJ8DLcI4ajL7muju1CSpakSK3Q9mZz6qqG0oakaK6dWfyGP3W/X9 SD0kegQUDu/Je236N4FZSiJNVAmeGRfyUvcoji+njJmhx2eHpqZRz2yZudCcyw5G kRqK23S/EFej0BHFIYHgYOsdbnwFaOkSphjiU= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 4E745A0A7F for ; Sun, 22 Nov 2009 22:37:08 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id CAC49A0A7E for ; Sun, 22 Nov 2009 22:37:07 -0500 (EST) Message-ID: <4B0A03C4.7030504@pobox.com> Date: Sun, 22 Nov 2009 19:38:44 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> <4B09FC30.4070107@bolyard.me> In-Reply-To: <4B09FC30.4070107@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 79F516B8-D7E1-11DE-8CFF-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 03:37:14 -0000 Nelson B Bolyard wrote: > > The purveyors of all those old non-compliant products are desperately > afraid that the browsers will unify and decide as a group to stop supporting > fall-back for extension intolerant servers. Then those old > servers would quickly become irrelevant. Can you try to do that? Get the browser vendors to all agree? I would applaud such a move. >> But the reality is old code takes a long time to die. That's why there >> is a thing called "maintenance." You might like to think that you can >> force all of this old code to get upgraded, but that's not going to >> happen. It needs to be _patched_! > > And the very first patch it needs to to finally comply with the 13 year > old specification that requires it to ignore unknown extensions. That's > not an upgrade. But with the RI proposal, that is not enough; they still would need to add support for extensions just to close this security hole. That is not a simple patch. Mike From mrex@sap.com Sun Nov 22 20:14:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8CF3A67D7 for ; Sun, 22 Nov 2009 20:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 mm63HhCnYHRM for ; Sun, 22 Nov 2009 20:14:29 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 9FB823A6782 for ; Sun, 22 Nov 2009 20:14:28 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAN4EKj9019162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 05:14:20 +0100 (MET) From: Martin Rex Message-Id: <200911230414.nAN4EJOX024665@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Mon, 23 Nov 2009 05:14:19 +0100 (MET) In-Reply-To: <4B09FC30.4070107@bolyard.me> from "Nelson B Bolyard" at Nov 22, 9 07:06:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 04:14:30 -0000 Nelson B Bolyard wrote: > > On 2009-11-22 18:30 PST, Michael D'Errico wrote: > > If you take an elitist position like the one you seem to be advocating, > > you run the risk that your "pure" standard-compliant fix will be ignored > > and people will come up with their own solutions. You will quickly > > become irrelevant. > > The purveyors of all those old non-compliant products are desperately > afraid that the browsers will unify and decide as a group to stop supporting > fall-back for extension intolerant servers. Then those old > servers would quickly become irrelevant. You seem to be on a different Internet than I am on. The statistics that I've seen show that a significant amount of users is not only several patches, but sometimes even several releases behind in a software. If you're going to break interoperability on the client side for a problem that is mostly cause by the architecture of the server-side application, then you will increase the number of people who are not going to use your latest-and-greatest but connectivity-impaired update or product. We don't know how many existing usage scenarios might break if we were so negligent. Now is a pretty bad time to start collecting these numbers, and breaking interoperability on purpose is a pretty expensive and offending way to obtain those numbers. Such a move may result in legal liability for those that sell software in some legislations. Sounds like casino engineering to me. -Martin From pgut001@wintermute01.cs.auckland.ac.nz Sun Nov 22 21:03:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C163B3A684F for ; Sun, 22 Nov 2009 21:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=-0.960, 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 QpvrICFx5hd9 for ; Sun, 22 Nov 2009 21:03:21 -0800 (PST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.37]) by core3.amsl.com (Postfix) with ESMTP id EAD8C3A6827 for ; Sun, 22 Nov 2009 21:03:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E2CEC483198; Mon, 23 Nov 2009 18:03:10 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BLA2SxH8XzF; Mon, 23 Nov 2009 18:03:10 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C5403482DCE; Mon, 23 Nov 2009 18:03:10 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NCR4w-00027Y-I5; Mon, 23 Nov 2009 18:03:10 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NCR4w-0001qS-Gy; Mon, 23 Nov 2009 18:03:10 +1300 From: Peter Gutmann To: mistone@akamai.com, tls@ietf.org In-Reply-To: <1258852287-sup-9453@usma1mc-aa5yjx> Message-Id: Sender: pgut001 Date: Mon, 23 Nov 2009 18:03:10 +1300 Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:03:21 -0000 Michael Stone writes: >For example, the "Client Browser Requirements" section of the US DISA's >guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that >must be enabled and disabled. Similarly, it seems likely that many contracts >have been written which mandate the use of FIPS 140-2-approved ciphers, e.g., >in order to establish compliance with the vague PCI-DSS "strong cryptography" >requirement. Does it say "ciphers" or "cipher suites"? This isn't enabling (or disabling) any ciphers at all, so it would seem to be excluded from the restrictions. (In any case if cipher suites really are explicitly restricted, you could always signal via compression algorithms). Peter. From pgut001@wintermute01.cs.auckland.ac.nz Sun Nov 22 21:28:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B96C3A699D for ; Sun, 22 Nov 2009 21:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=-0.720, 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 q5I+Vo59J9k4 for ; Sun, 22 Nov 2009 21:28:29 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 498B23A6992 for ; Sun, 22 Nov 2009 21:28:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E41499DAC3; Mon, 23 Nov 2009 18:28:24 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpcAI4WAYN9Y; Mon, 23 Nov 2009 18:28:24 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C19209DAC2; Mon, 23 Nov 2009 18:28:24 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NCRTM-0003KA-IY; Mon, 23 Nov 2009 18:28:24 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NCRTM-0003PE-KQ; Mon, 23 Nov 2009 18:28:24 +1300 From: Peter Gutmann To: jsalowey@cisco.com, tls@ietf.org In-Reply-To: Message-Id: Sender: pgut001 Date: Mon, 23 Nov 2009 18:28:24 +1300 Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:28:30 -0000 "Joseph Salowey (jsalowey)" writes: >Support for the draft: >- I would support an entirely different proposal (please identify it; be >specific) I support the (somewhat ongoing) one-size-fits-all signalling + changed- Finished proposal initiated by Martin. I can't be too specific at the moment because it's still evolving, but it seems to be moving in a positive direction. It's simpler, more straightforward, and most of all less of a Russian-roulette game in the face of any number of oddball implementations. Peter. From jsalowey@cisco.com Sun Nov 22 21:32:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36EB3A67A7 for ; Sun, 22 Nov 2009 21:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 9wDb6-DcjZUo for ; Sun, 22 Nov 2009 21:32:21 -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 341353A684F for ; Sun, 22 Nov 2009 21:32:21 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB6tCUurR7H+/2dsb2JhbAC8TpZLhDwE X-IronPort-AV: E=Sophos;i="4.47,269,1257120000"; d="scan'208";a="438417239" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 23 Nov 2009 05:32:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAN5WH4p020629 for ; Mon, 23 Nov 2009 05:32:17 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.3959); Sun, 22 Nov 2009 21:32:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Nov 2009 21:32:16 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes from IETF 76 Thread-Index: Acpr/lF0unksuTRqQNqUO3OF488qyg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 23 Nov 2009 05:32:17.0707 (UTC) FILETIME=[521E67B0:01CA6BFE] Subject: [TLS] Minutes from IETF 76 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:32:22 -0000 I Posted draft minutes from the IETF-76 meeting at http://www.ietf.org/proceedings/09nov/minutes/tls.txt. Please send correction by December 9, 2009. Thanks to Sean Turner for taking notes. Cheers, Joe From pgut001@wintermute01.cs.auckland.ac.nz Sun Nov 22 21:55:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87BC3A6A13 for ; Sun, 22 Nov 2009 21:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.175 X-Spam-Level: X-Spam-Status: No, score=-5.175 tagged_above=-999 required=5 tests=[AWL=1.424, 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 XB4C6EGn0DBN for ; Sun, 22 Nov 2009 21:55:27 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id D8ECD3A6A0F for ; Sun, 22 Nov 2009 21:55:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2F85641474E; Mon, 23 Nov 2009 18:55:14 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW0lB6ss7wuP; Mon, 23 Nov 2009 18:55:14 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 12433414747; Mon, 23 Nov 2009 18:55:13 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NCRtJ-0004Zo-I9; Mon, 23 Nov 2009 18:55:13 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NCRtJ-0004um-Hc; Mon, 23 Nov 2009 18:55:13 +1300 From: Peter Gutmann To: mike-list@pobox.com, tls@ietf.org In-Reply-To: <4B081066.4040903@pobox.com> Message-Id: Sender: pgut001 Date: Mon, 23 Nov 2009 18:55:13 +1300 Subject: Re: [TLS] Non-browser clients. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:55:27 -0000 Michael D'Errico writes: >I've been meaning to bring this up too. My TLS library knows nothing of >sockets or even file descriptors. It is just a string processor. Above that >is my socket library, and conceivable I could create a different class that >communicates over a serial line or other connection type. Same here. TLS has been specified for use in rather strange environments like industrial process control where you're moving data over nothing I'm familiar with (the references in, for example, IEC 62351 are to industrial-comms standards that I didn't recognise) and you not only don't have control over the comms layer but even if you did you may be on a permanent virtual circuit for which "drop the connecting and reconnect" doesn't make much sense. The problem with TLS-everywhere is that it really has ended up everywhere, not just on things that talk TCP/IP. Peter. From fweimer@bfk.de Sun Nov 22 23:29:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBD63A67F0 for ; Sun, 22 Nov 2009 23:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQX9kEVpVLXp for ; Sun, 22 Nov 2009 23:29:01 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id D39D43A67EC for ; Sun, 22 Nov 2009 23:28:59 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1NCTLy-0006tY-1s; Mon, 23 Nov 2009 08:28:54 +0100 Received: by bfk.de with local id 1NCTLy-0002Sg-4u; Mon, 23 Nov 2009 07:28:54 +0000 To: Michael Stone References: <20091120000001.7D25D3A6840@core3.amsl.com> <1258852287-sup-9453@usma1mc-aa5yjx> From: Florian Weimer Date: Mon, 23 Nov 2009 07:28:54 +0000 In-Reply-To: <1258852287-sup-9453@usma1mc-aa5yjx> (Michael Stone's message of "Sat\, 21 Nov 2009 20\:11\:36 -0500") Message-ID: <82vdh1hf7t.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:29:02 -0000 * Michael Stone: > For example, the "Client Browser Requirements" section of the US DISA's > guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that= must > be enabled and disabled. Similarly, it seems likely that many contracts h= ave > been written which mandate the use of FIPS 140-2-approved ciphers, e.g., = in > order to establish compliance with the vague PCI-DSS "strong cryptography" > requirement. But it turned out that all those cipher suites were not as secure as expected. You need to invoke the flaw remediation procedures. For UNIX STIG V5R1, this appears to require an IAVM. While this may take some time, I don't think this is an argument against magic cipher suites. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Sun Nov 22 23:35:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22E13A6832 for ; Sun, 22 Nov 2009 23:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceYe+K-g0HUa for ; Sun, 22 Nov 2009 23:35:17 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id D1EFC3A659B for ; Sun, 22 Nov 2009 23:35:16 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1NCTS0-0007e6-6y; Mon, 23 Nov 2009 08:35:08 +0100 Received: by bfk.de with local id 1NCTRz-0008Rn-TY; Mon, 23 Nov 2009 07:35:08 +0000 To: Peter Gutmann References: From: Florian Weimer Date: Mon, 23 Nov 2009 07:35:07 +0000 In-Reply-To: (Peter Gutmann's message of "Mon\, 23 Nov 2009 18\:03\:10 +1300") Message-ID: <82r5rphexg.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:35:17 -0000 * Peter Gutmann: > Michael Stone writes: > >>For example, the "Client Browser Requirements" section of the US DISA's >>guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that >>must be enabled and disabled. Similarly, it seems likely that many contra= cts >>have been written which mandate the use of FIPS 140-2-approved ciphers, e= .g., >>in order to establish compliance with the vague PCI-DSS "strong cryptogra= phy" >>requirement. > > Does it say "ciphers" or "cipher suites"? This isn't enabling (or disabl= ing) > any ciphers at all, so it would seem to be excluded from the restrictions. Cipher suites, as far as I can tell. Both SSLv2 and SSLv3 are mandatory, and TLS is not allowed (if you view the list of protocols as exhaustive). --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Pasi.Eronen@nokia.com Sun Nov 22 23:36:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D90A3A67EC for ; Sun, 22 Nov 2009 23:36:56 -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 28EM33TTi3ro for ; Sun, 22 Nov 2009 23:36:55 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D81FF3A659B for ; Sun, 22 Nov 2009 23:36:55 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAN7aknu019779; Mon, 23 Nov 2009 01:36:51 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 09:36:14 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 09:36:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 09:36:09 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 23 Nov 2009 08:35:50 +0100 From: To: , Date: Mon, 23 Nov 2009 08:35:49 +0100 Thread-Topic: [TLS] user requirements for TLS fix Thread-Index: Acpop0ZnitJXh1SQRAOwgobuEoUVdADZxZQA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3104EDB4@NOK-EUMSG-01.mgdnok.nokia.com> References: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> <808FD6E27AD4884E94820BC333B2DB774F30FE105B@NOK-EUMSG-01.mgdnok.nokia.com> <4B048383.5010605@jacaranda.org> In-Reply-To: <4B048383.5010605@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 07:36:09.0592 (UTC) FILETIME=[9FDE0F80:01CA6C0F] X-Nokia-AV: Clean Subject: Re: [TLS] user requirements for TLS fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:36:56 -0000 RGF2aWQtU2FyYWggSG9wd29vZCB3cm90ZToNCg0KPiA+IEJ1dCBzZXJ2ZXJzIHRoYXQgbmV2ZXIg YWxsb3dlZCByZW5lZ290aWF0aW9uIHRvIGJlZ2luIHdpdGggYXJlIG5vdA0KPiA+IHZ1bG5lcmFi bGUsIGFuZCBtYW55IG90aGVycyBjYW4ganVzdCBkaXNhYmxlIHJlbmVnb3RpYXRpb24gKHdpdGhv dXQNCj4gPiBpbXBsZW1lbnRpbmcgYW55dGhpbmcgZWxzZSkuIFRoZXNlIHNlcnZlcnMgd29uJ3Qg aGF2ZSBhbnkgbmVlZA0KPiA+IHRvIHBhdGNoLCBhbmQgd2lsbCBiZSBhcm91bmQgInVucGF0Y2hl ZCIgbXVjaCBsb25nZXIgdGhhbiBhIHllYXINCj4gPiBmcm9tIG5vdy4NCj4gDQo+IEFsbCBzZXJ2 ZXJzLCByZWdhcmRsZXNzIG9mIHRoZWlyIHZ1bG5lcmFiaWxpdHksIHdpbGwgaGF2ZSB0byBwYXRj aCBpZg0KPiB0aGV5IGFyZSB0byByZW1haW4gaW50ZXJvcGVyYWJsZSB3aXRoIHN0cmljdCBjbGll bnRzLg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCB3YXlzIGhvdyB0aGlzIHN5c3RlbSBjb3VsZCBnby4g U29tZSBwb3NzaWJpbGl0aWVzOg0KDQoxKSBzb21lb25lIHNoaXBzIGEgInN0cmljdCBjbGllbnQi ICh0aGF0IGNvbXBsYWlucyB0byB1c2VyIHdoZW4NCmRldGVjdGluZyBhbiB1bnBhdGNoZWQgc2Vy dmVyIikgLS0+IHVzZXJzIGdldCBhbm5veWVkIC0tPiB1c2Vycw0KY29tcGxhaW4gdG8gc2VydmVy IG93bmVycyAtLT4gd2hvbGUgd29ybGQgdXBncmFkZXMgdGhlaXIgc2VydmVycyANCihldmVuIHRo b3NlIHRoYXQgbmV2ZXIgd2VyZSB2dWxuZXJhYmxlKQ0KDQoyKSBzb21lb25lIHNoaXBzIGEgInN0 cmljdCBjbGllbnQiIC0tPiB1c2VycyBnZXQgYW5ub3llZCAtLT4gdXNlcnMNCmNvbXBsYWluIHRv IGNsaWVudCB2ZW5kb3IgLS0+IHN0cmljdCBtb2RlIGlzIHR1cm5lZCBvZmYgaW4gdGhlIGNsaWVu dA0KDQozKSBzb21lb25lIHNoaXBzIGEgInN0cmljdCBjbGllbnQiIC0tPiB1c2VycyBnZXQgYW5u b3llZCAtLT4gdXNlcnMNCmNvbXBsYWluIHRvIHNlcnZlciBvd25lcnMgLS0+IHNlcnZlciBvd25l cnMgKGNvcnJlY3RseSkgc2F5IHRoZXkncmUNCnNlY3VyZSBhbHJlYWR5IC0tPiB1c2VycyBjb21w bGFpbiB0byBjbGllbnQgdmVuZG9yIC0tPiBzdHJpY3QgbW9kZSANCmlzIHR1cm5lZCBvZmYNCg0K KEFuZCBzZXZlcmFsIHZhcmlhdGlvbnMgb2YgdGhlc2UuKQ0KDQpNeSBwZXJzb25hbCBvcGluaW9u IGlzIHRoYXQgIzEgaXMgdGhlICpsZWFzdCogbGlrZWx5IGNvdXJzZSBvZiBldmVudHMNCihhbmQg IzIvIzMgLS0gb3Igc29tZSBzaW1pbGFyIHNpdHVhdGlvbiB3aGVyZSB0aGUgZW5kIHJlc3VsdCBp cyBub2JvZHkNCnVzaW5nIHN0cmljdCBtb2RlIC0tIGlzIG1vcmUgbGlrZWx5KSwgYnV0IHRoaXMg b3BpbmlvbiBpcyBjbGVhcmx5DQpiYXNlZCBvbiAiZ3V0IGZlZWxpbmciLCBub3QgaGFyZCBmYWN0 cywgc28gSSByZWFsaXplIG90aGVycyBtYXkNCnJlYXNvbmFibHkgYXJyaXZlIGF0IGEgZGlmZmVy ZW50IGNvbmNsdXNpb24uDQoNCkJlc3QgcmVnYXJkcywNClBhc2kNCihub3Qgd2VhcmluZyBhbnkg aGF0cykNCg0K From djhopwood@googlemail.com Sun Nov 22 23:44:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F183A684C for ; Sun, 22 Nov 2009 23:44: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 V8eWyfEvBNEF for ; Sun, 22 Nov 2009 23:44:37 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 3D3793A67EC for ; Sun, 22 Nov 2009 23:44:37 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so132483eyf.51 for ; Sun, 22 Nov 2009 23:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=s8lLoVAVEGd1ky4XbwkAUUo2Y96G0C1Xc1O7ObPFsuA=; b=awgQQ6DA/6rmV3Uujy8kOSnXUrpHxANvtjR/QdzmqLS21l74FawGlFRrpTf3flh3Hs +TxZnl1QYUwfN9P3jfpotDr8GGcrBcUlcDcWlry+rNxL8DHkYXczTWkLKTpMknhr7VFX D2reBGHkP5gaXTncbcg1DJKiXcgOkFSnUeEF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=HApArPVj8wGQct88BaHWVQm7pstzNQNzaVrXZCjzPGKzD78uADzMaARVxXTmT58VQg 4pTVH6Wo1Wg3M34qnx4JWHM+rSej2JKq3prWzMxB2Fqzg2LYOTcTPCIriJlFc3nWE9Dr +X4uM2xfk/0OKJEg1NaWCkqFg/wLNyPMej72s= Received: by 10.213.104.10 with SMTP id m10mr4250861ebo.62.1258962269260; Sun, 22 Nov 2009 23:44:29 -0800 (PST) Received: from ?192.168.0.2? (5e0251ec.bb.sky.com [94.2.81.236]) by mx.google.com with ESMTPS id 13sm269800ewy.1.2009.11.22.23.44.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Nov 2009 23:44:28 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0A3D59.2060508@jacaranda.org> Date: Mon, 23 Nov 2009 07:44:25 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911191921.nAJJLtwF007361@fs4113.wdf.sap.corp> <4B059FFC.1000903@extendedsubset.com> <4B09B3EB.5020803@bolyard.me> In-Reply-To: <4B09B3EB.5020803@bolyard.me> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig132497399045A8E91539846B" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:44:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig132497399045A8E91539846B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nelson B Bolyard wrote: > The "fall back" logic about which so much discussion has taken place in= this > mailing list is not implemented in NSS. It is a part of the Mozilla > browsers, outside (on top) of NSS. It exists solely because of servers= > that are intolerant of extensions (that refuse to negotiate a handshake= if > ANY extension is present), and because of broken old SSL 3.0 servers th= at > cannot successfully negotiate SSL 3.0 when the client offers any other > version. > > That fall back logic is now 11 years old. I think it has served its us= eful > lifetime. I think the purveyors of those broken non-compliant old serv= ers > have had PLENTY of time to make their server correctly negotiate SSL 3.= 0 > even when the client asks for TLS, and PLENTY of time to change to igno= re > all hello extensions. > > The browsers have not had a good reason to drop fall-back logic, until = now. > But now, the newly found vulnerability in those old servers is, IMO, re= ason > enough for the browsers to disable that old fall back logic, and begin = to > require what (IMO) they should have required a decade ago, that servers= > actually do conform to the specifications to which they claim to confor= m, > and CORRECTLY implement protocol version negotiation, and correctly ign= ore > all non-recognized extensions. I couldn't agree more. Also, I believe this issue of TLS- and extension-intolerance has been greatly overemphasized in the discussions so far. There is no evidence that this kind of bug currently affects more than a tiny minority of server implementations. Note that in , a single server/frontend implementation -- Lotus Domino WebSphere -- is implicated in four of the six examples given (A2, A3, A4, and A5). However, WebSphere was fixed to be TLS-tolerant in version 5.0.9, which was released no later than 2002 (the fix is mentioned here: ). Now, this does not exclude the possibility that WebSphere was just a convenient example of a more widespread problem. But the 'interop-experience' draft doesn't provide any evidence of that, and I've been unable to find any other evidence that would support it. Consider for example the Mozilla tracking bug for TLS-intolerant servers: If we try to connect to each of those sites mentioned in that bug, the ones that still exist *all* have certificates with domain name mismatches. Therefore, connections to those servers are vulnerable to a MITM attack, and it would be correct to refuse to interoperate with them for that reason. Note that in the case of web browsers, there are typically options for a user to override mismatched certs and similar problems for particular sites -- in Firefox these are called "Security Exceptions" in the user interface. So, if implementors of a browser that already has a fallback wanted to maintain it in order to avoid regressions in connecting to currently working sites, one possibility would be to allow the fallback only for sites in the security exception list. Together with implementing the RI draft, that would eliminate the possibility of both version downgrade attacks and renegotiation attacks with no user warning, and it would not introduce any additional security problem (because if a user registers an exception for a domain name, then a MITM attack against that domain is possible anyway). For clients that don't already have a fallback, OTOH, I can see no good rationale for adding one. This issue should not be considered an obstacle to solutions to the renegotiation flaw that use extensions. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig132497399045A8E91539846B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksKPWIACgkQWUc8YzyzqAd5IgD+JoeLnfiLJ/e/lc5WPKRMIweO QeQfwsNMqacTWz8+hUAA/i6ZpHD5VqLrSaboiyfRk0CFuUy2+ipxLmajyEj6ly/3 =80oX -----END PGP SIGNATURE----- --------------enig132497399045A8E91539846B-- From djhopwood@googlemail.com Sun Nov 22 23:49:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4403A69F5 for ; Sun, 22 Nov 2009 23:49:07 -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 J0nAaGqYYCK0 for ; Sun, 22 Nov 2009 23:49:07 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id CEC9B3A67F0 for ; Sun, 22 Nov 2009 23:49:06 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so133043eyf.51 for ; Sun, 22 Nov 2009 23:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=7QnioJOq7xaz6ED94dzGAbGhuoa7vX6SvwwVOJB2N7Q=; b=cp43BNA4VIdINrTFEwow3CMJFT+u8ppLis/XruNAJozaumvaZlZc2sdUpAxH1/+hB1 zfMAbydpks7AW6f7rJ2Wt+O5z3T5bXnPsGFfir7t2VJ5bOqMB7Wphwa3SL5SzUaR1aUY fwnF3HOXZnoE5APhX6xkQ/sivx6QH+qCXz9+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=UIEVDjSCpfsTmogwzyUaaUrdE0EjlsyrVWM0NYTu+ix7jyVXhsw/hURgWN0sMjKoDO DoMqgZrfxqQ6jokHINu2RAsLZDbuRJGVFMYgujRE1NQtclKXfdYeM84sk8kpohhclXnK lKKO2oEXid7zgIeDn0u9Cq/BUz+6kzeza4KpU= Received: by 10.216.89.12 with SMTP id b12mr1411580wef.93.1258962538774; Sun, 22 Nov 2009 23:48:58 -0800 (PST) Received: from ?192.168.0.2? (5e0251ec.bb.sky.com [94.2.81.236]) by mx.google.com with ESMTPS id 28sm577862eye.9.2009.11.22.23.48.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Nov 2009 23:48:57 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0A3E70.4070603@jacaranda.org> Date: Mon, 23 Nov 2009 07:49:04 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <82r5rphexg.fsf@mid.bfk.de> In-Reply-To: <82r5rphexg.fsf@mid.bfk.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigEE12CF064648B11A1DCA5106" Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:49:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE12CF064648B11A1DCA5106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Florian Weimer wrote: >> Michael Stone writes: >> >>> For example, the "Client Browser Requirements" section of the US DISA= 's >>> guidance document "UNIX STIG V5R1" mandates an exact list of ciphers = that >>> must be enabled and disabled. Similarly, it seems likely that many co= ntracts >>> have been written which mandate the use of FIPS 140-2-approved cipher= s, e.g., >>> in order to establish compliance with the vague PCI-DSS "strong crypt= ography" >>> requirement. >> Does it say "ciphers" or "cipher suites"? This isn't enabling (or dis= abling) >> any ciphers at all, so it would seem to be excluded from the restricti= ons. >=20 > Cipher suites, as far as I can tell. Both SSLv2 and SSLv3 are > mandatory, and TLS is not allowed (if you view the list of protocols > as exhaustive). Then it's mandating insecurity. Why would you want to follow this guidanc= e? --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigEE12CF064648B11A1DCA5106 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF0EAREIAAYFAksKPnAACgkQWUc8YzyzqAewOwD4o0wyegTvLrDRVE+EQpPRuZx6 Ojvc6zdKH6HUwjdBEwD/aXXZ6O7ZyyxEldGrTVxmwg3KuQCTmPeKvtit7r3bosA= =TjLz -----END PGP SIGNATURE----- --------------enigEE12CF064648B11A1DCA5106-- From djhopwood@googlemail.com Sun Nov 22 23:54:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9C93A68C8 for ; Sun, 22 Nov 2009 23:54:05 -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 Ot0rvBDwLGAT for ; Sun, 22 Nov 2009 23:54:04 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 88E3F3A6850 for ; Sun, 22 Nov 2009 23:54:03 -0800 (PST) Received: by ewy7 with SMTP id 7so1571766ewy.28 for ; Sun, 22 Nov 2009 23:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=iYfkXsU0kX4V0F83OQ1g20rV4FZdK0ceaMA//vLE5ZY=; b=H8xs6HZCN3efprS/Dg4LJ/8OUqM1Wl1AWa3FrcFYKHnq81cht6MqjI5s2cOY907i6O dOm2wXzKjXfEiMmKVrKkLHdoifjGuizWzqg6CsdJ8kiKfBfGv0RKUMWViMY8UMWPXzDW gsEuxG2DuS3H8Vb8otreb4lE09SJ0sRj573mY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=tdjiX6CIv1plNike2ItYDkNC1EmyAdmg+/WeTfTYi+bQtUTfnZwesmnU9FycvdbLy/ BGpAWKPAqaCwWJug1a0lioUqB3cAn2a6LD0HWkz7/G+izgSVjZzJwXvkOiA2ITIa82Qj cdMN0aUpV6m/TfpJpBc3DHSGJXChBQSxtC0qM= Received: by 10.213.21.10 with SMTP id h10mr4464483ebb.17.1258962836513; Sun, 22 Nov 2009 23:53:56 -0800 (PST) Received: from ?192.168.0.2? (5e0251ec.bb.sky.com [94.2.81.236]) by mx.google.com with ESMTPS id 10sm967766eyz.7.2009.11.22.23.53.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Nov 2009 23:53:55 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0A3F9A.1030602@jacaranda.org> Date: Mon, 23 Nov 2009 07:54:02 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <52142EEBD53E68C92E2B2533@446E7922C82D299DB29D899F> <808FD6E27AD4884E94820BC333B2DB774F30FE105B@NOK-EUMSG-01.mgdnok.nokia.com> <4B048383.5010605@jacaranda.org> <808FD6E27AD4884E94820BC333B2DB774F3104EDB4@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3104EDB4@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3919BFE752D8A3186BD12F52" Subject: Re: [TLS] user requirements for TLS fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:54:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3919BFE752D8A3186BD12F52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pasi.Eronen@nokia.com wrote: > David-Sarah Hopwood wrote: >=20 >>> But servers that never allowed renegotiation to begin with are not >>> vulnerable, and many others can just disable renegotiation (without >>> implementing anything else). These servers won't have any need >>> to patch, and will be around "unpatched" much longer than a year >>> from now. >> >> All servers, regardless of their vulnerability, will have to patch if >> they are to remain interoperable with strict clients. >=20 > There are several ways how this system could go. Some possibilities: >=20 > 1) someone ships a "strict client" (that complains to user when > detecting an unpatched server") --> users get annoyed --> users > complain to server owners --> whole world upgrades their servers=20 > (even those that never were vulnerable) >=20 > 2) someone ships a "strict client" --> users get annoyed --> users > complain to client vendor --> strict mode is turned off in the client >=20 > 3) someone ships a "strict client" --> users get annoyed --> users > complain to server owners --> server owners (correctly) say they're > secure already --> users complain to client vendor --> strict mode=20 > is turned off >=20 > (And several variations of these.) Some clients *will* be strict, even if those are not web browsers. I suppose it is possible that the web will take a long time to catch up to requiring security against this attack; it always does. But it will eventually catch up, even if it takes as long as it did to disable SSLv2 in most clients. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig3919BFE752D8A3186BD12F52 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksKP5oACgkQWUc8YzyzqAdfLgEAghT2GY/xmKq1C/d9dr8ZeaTL sMYtyAvabOGzd7U+ir0BAJKYygiBH37OFEkGYlJxDsWGJBPpuCHdlR+M/sdaLhyj =RYQX -----END PGP SIGNATURE----- --------------enig3919BFE752D8A3186BD12F52-- From djhopwood@googlemail.com Mon Nov 23 00:16:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A393A68C5 for ; Mon, 23 Nov 2009 00:16:08 -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 FzQSZip5WVmm for ; Mon, 23 Nov 2009 00:16:07 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 3D9E93A6892 for ; Mon, 23 Nov 2009 00:16:06 -0800 (PST) Received: by bwz23 with SMTP id 23so4946595bwz.29 for ; Mon, 23 Nov 2009 00:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=6yVbMBVDph6RghWU/Joobp/2E9mY6w4aM8zN0Z0BEvQ=; b=w1Jm9tkkROV4e3WJuxNdgctXWwXzQrkqZdymuGPkeAMpk1DqWxHpjk8bZ+uOxUqV5F GNb3woQoYeMEk2jqbt2mQntkHVoqZOZv977CPVOSt0Dq046ZGv4WvZlkvbBblenBwY6S EQeSxqcAQXIswasK4n5s5+656ma5LwlBUZg7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=yIWtkNKINlN5CyuToKI+ib/41QxRcUfstGL+CE379DvMBxYSWs/I3UpntO9HoWipvU gwm0+pQPFjv9AG1nm8Y2/IJurmYEmJhrcKceH1DhIp07s+y6LJV3wmpck4FDDV8lYVw4 Vt4w3ykMUGtNglBhG67twUVgVAmaNKOkKWcBY= Received: by 10.204.3.14 with SMTP id 14mr4381705bkl.128.1258964160007; Mon, 23 Nov 2009 00:16:00 -0800 (PST) Received: from ?192.168.0.2? (5e0251ec.bb.sky.com [94.2.81.236]) by mx.google.com with ESMTPS id 15sm1278382fxm.14.2009.11.23.00.15.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 00:15:59 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0A44C5.4080608@jacaranda.org> Date: Mon, 23 Nov 2009 08:16:05 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> <4B09FC30.4070107@bolyard.me> <4B0A03C4.7030504@pobox.com> In-Reply-To: <4B0A03C4.7030504@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig6B0B1DC233F2ED078CB485E6" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:16:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B0B1DC233F2ED078CB485E6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > Nelson B Bolyard wrote: >> >> The purveyors of all those old non-compliant products are desperately >> afraid that the browsers will unify and decide as a group to stop >> supporting >> fall-back for extension intolerant servers. Then those old >> servers would quickly become irrelevant. > > Can you try to do that? Get the browser vendors to all agree? Quite possibly. But to do that, the discussion needs to pay more attentio= n to the actual frequency of extension-intolerance bugs, rather than assumi= ng that mere existence of such bugs is a show-stopper. Browser implementors care about *how often* thinks break; they are not absolutists. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig6B0B1DC233F2ED078CB485E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksKRMUACgkQWUc8YzyzqAeOlgEAoTh0sg1G1iFqgAVCyLj8eHLZ ApFimmx8eeiCngM1fp4A/RilwRer8/vslAQqM9JwXcHY2m9zj6X0KbUxkE6OrEUL =xhMk -----END PGP SIGNATURE----- --------------enig6B0B1DC233F2ED078CB485E6-- From stefan@aaa-sec.com Mon Nov 23 00:33:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67CB03A6892 for ; Mon, 23 Nov 2009 00:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCvd-WOSvDjr for ; Mon, 23 Nov 2009 00:33:39 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 9B4593A685B for ; Mon, 23 Nov 2009 00:33:39 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BD2B92929A3 for ; Mon, 23 Nov 2009 09:33:35 +0100 (CET) Received: (qmail 1605 invoked from network); 23 Nov 2009 08:33:33 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Nov 2009 08:33:33 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 23 Nov 2009 09:33:31 +0100 From: Stefan Santesson To: Nelson B Bolyard , Message-ID: Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: AcpsF6MbXYtYPlPxJkS/WI186JvBMQ== In-Reply-To: <4B09ECAB.7050205@bolyard.me> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:33:40 -0000 Could you elaborate on this? I've looked through the SSLv3 spec and couldn't find any evidence that support this claim. On 09-11-23 3:00 AM, "Nelson B Bolyard" wrote: > That also applies to specification compliant SSL 3.0 servers, which were > always supposed to ignore extra data in the client hellos. It seems to me that the original client hello syntax was defined without extensibility. /Stefan From ynir@checkpoint.com Mon Nov 23 00:56:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C703A6A26 for ; Mon, 23 Nov 2009 00:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 aqAoUEXo7TF9 for ; Mon, 23 Nov 2009 00:56:44 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 792973A6A20 for ; Mon, 23 Nov 2009 00:56:43 -0800 (PST) X-CheckPoint: {4B0A4AA4-1-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1D3CA29C00B; Mon, 23 Nov 2009 10:56:39 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 07D8929C002; Mon, 23 Nov 2009 10:56:39 +0200 (IST) X-CheckPoint: {4B0A4AA3-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAN8ucGo025021; Mon, 23 Nov 2009 10:56:38 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 23 Nov 2009 10:56:43 +0200 From: Yoav Nir To: Nelson B Bolyard Date: Mon, 23 Nov 2009 10:56:36 +0200 Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: AcpsGuD4ZhxGo6ZmRUSxFQAhZChD1Q== Message-ID: <64E272FB-7420-4B6A-B649-38487A539EF5@checkpoint.com> References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> <4B09FC30.4070107@bolyard.me> In-Reply-To: <4B09FC30.4070107@bolyard.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:56:44 -0000 On Nov 23, 2009, at 5:06 AM, Nelson B Bolyard wrote: > On 2009-11-22 18:30 PST, Michael D'Errico wrote: >> If you take an elitist position like the one you seem to be advocating, >> you run the risk that your "pure" standard-compliant fix will be ignored >> and people will come up with their own solutions. You will quickly >> become irrelevant. >=20 > The purveyors of all those old non-compliant products are desperately > afraid that the browsers will unify and decide as a group to stop support= ing > fall-back for extension intolerant servers. Then those old > servers would quickly become irrelevant. Actually, patching servers is a lot easier than patching browsers. It's fai= rly easy for a server administrator to replace the necessary library (OpenS= SL 0.9.8m?) with one that does TLS 1.3 and then we don't need any extension= s. But these same servers need to support all the clients out there. That incl= udes the latest Firefox, but also the ever-prevalent IE6 on XP (with and wi= thout patches and service packs), as well as an old iMac running Mac OS 8.6= with a Mozilla browser, and various phones. So if the browsers unify, that's great. Maybe the browsers will standardize= on TLS 1.3 and we can drop support for all older versions the moment we de= cide that it's time to drop support for all pre-2010 browsers. I think 202= 2 should do it. In the meantime, we can't ignore that IE6 running on no-SP Windows XP.= From nelson@bolyard.me Mon Nov 23 01:19:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8DB3A657C for ; Mon, 23 Nov 2009 01:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 hagkbiBnj0um for ; Mon, 23 Nov 2009 01:19:33 -0800 (PST) Received: from p3plsmtpa01-01.prod.phx3.secureserver.net (p3plsmtpa01-01.prod.phx3.secureserver.net [72.167.82.81]) by core3.amsl.com (Postfix) with SMTP id 3330A3A69BF for ; Mon, 23 Nov 2009 01:19:33 -0800 (PST) Received: (qmail 29339 invoked from network); 23 Nov 2009 09:19:27 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 23 Nov 2009 09:19:27 -0000 Message-ID: <4B0A536B.6050002@bolyard.me> Date: Mon, 23 Nov 2009 01:18:35 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:19:34 -0000 On 2009-11-23 00:33 PST, Stefan Santesson wrote: > Could you elaborate on this? > > I've looked through the SSLv3 spec and couldn't find any evidence that > support this claim. The copy of the SSL 3.0 spec on which I've always relied is found at http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt On the top of page 24, it says: Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. > On 09-11-23 3:00 AM, "Nelson B Bolyard" wrote: > >> That also applies to specification compliant SSL 3.0 servers, which were >> always supposed to ignore extra data in the client hellos. > > It seems to me that the original client hello syntax was defined without > extensibility. > > /Stefan From yaronf@checkpoint.com Mon Nov 23 01:24:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF9B3A6898 for ; Mon, 23 Nov 2009 01:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JsQAWxl0ZpG for ; Mon, 23 Nov 2009 01:24:08 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EEB843A657C for ; Mon, 23 Nov 2009 01:24:07 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAN9O2Go002543 for ; Mon, 23 Nov 2009 11:24:02 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 23 Nov 2009 11:24:08 +0200 From: Yaron Sheffer To: "tls@ietf.org" Date: Mon, 23 Nov 2009 11:24:06 +0200 Thread-Topic: Server-only solution - proposed text Thread-Index: AcpsHrQfc2dpXjJbQye8ntQsVgpoVg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DCilex01adche_" MIME-Version: 1.0 Subject: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:24:17 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DCilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin's I= -D-to-be) are making changes to the protocol, and therefore will only becom= e effective once a good percentage of clients have been patched. In the mea= ntime, administrators could fix their (patched) servers locally in many cas= es, without waiting for the client population to get fixed. I propose to ad= d the following short section to both drafts: X. Server-Side Mitigation Procedures We assume that it will take a significant amount of time until the protocol= change defined in this document is adopted by all clients. However, in man= y cases a server-only mitigation is possible in the interim: many TLS appli= cations, and in particular, many Web (HTTPS) applications, do not require r= enegotiation for proper operation. Implementations of the current document = (unless they employ a strict policy, allowing only protected clients to con= nect) SHOULD be configurable to disallow TLS renegotiation with vulnerable = clients. The following three settings are RECOMMENDED: - Allow any renegotiation with unprotected clients. - Allow only server-initiated renegotiation with unprotected clients. - Disallow renegotiation with unprotected clients.. The default setting is a matter of vendor and/or local policy. [Note: this contradicts the sentence "Servers SHOULD NOT allow clients to r= enegotiate without using this extension" in the Security Considerations of = draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be foll= owed by many implementers.] Thanks, Yaron --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DCilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Both proposals on the table (draft-ietf-tls-renegotiatio= n-00 and Martin’s I-D-to-be) are making changes to the protocol, and there= fore will only become effective once a good percentage of clients have been patched. = In the meantime, administrators could fix their (patched) servers locally in m= any cases, without waiting for the client population to get fixed. I propose to= add the following short section to both drafts:

 

X. Server-Side Mitigation Procedures

 

We assume that it will take a significant amount of time until the protocol change defined in this document is adopted by all client= s. However, in many cases a server-only mitigation is possible in the interim: many TLS applications, and in particular, many Web (HTTPS) applications, do not requ= ire renegotiation for proper operation. Implementations of the current document= (unless they employ a strict policy, allowing only protected clients to connect) SH= OULD be configurable to disallow TLS renegotiation with vulnerable clients. The = following three settings are RECOMMENDED:

 

-       Allow any renegoti= ation with unprotected clients.

-       Allow only server-= initiated renegotiation with unprotected clients.

-       Disallow renegotia= tion with unprotected clients..

 

The default setting is a matter of vendor and/or local policy.

 

[Note: this contradicts the sentence “Servers SHOU= LD NOT allow clients to renegotiate without using this extension” in the Sec= urity Considerations of draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be followed by many implementers.]

 

Thanks,

         &n= bsp;  Yaron

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DCilex01adche_-- From simon@josefsson.org Mon Nov 23 01:29:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1873A6898 for ; Mon, 23 Nov 2009 01:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 M8ibB4rtrHLC for ; Mon, 23 Nov 2009 01:29:19 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 6166D3A657C for ; Mon, 23 Nov 2009 01:29:19 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAN9T87s004584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2009 10:29:09 +0100 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091123:jsalowey@cisco.com::f3yHFN5fxTPQUB1I:3dDe X-Hashcash: 1:22:091123:tls@ietf.org::EuV7G6YQmVN46HzZ:4PNG Date: Mon, 23 Nov 2009 10:29:08 +0100 In-Reply-To: (Joseph Salowey's message of "Fri, 20 Nov 2009 13:53:27 -0800") Message-ID: <87d439wpwb.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:29:20 -0000 "Joseph Salowey (jsalowey)" writes: > Support for the draft: > - I support this draft > - I support this draft with the following modification > - I would support an entirely different proposal (please identify it; be > specific) I would support Martin Rex's upcoming draft which provides a general solution that works for both SSLv3 and TLS, instead of using a dirty hack that only works for TLS. However I would like to see more analysis of Martin Rex's proposal before making a decision. Right now I only see advantages with Martin's proposal and no disadvantages with it, while I see clear disadvantages with RI and no advantages with RI that Martin's proposal doesn't also have. If that is really the case, Martin's draft will have my support, but there could be some detail that has been overlooked so far. /Simon From Pasi.Eronen@nokia.com Mon Nov 23 03:19:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9733A6A3E for ; Mon, 23 Nov 2009 03:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 oxfG1ar6EtYA for ; Mon, 23 Nov 2009 03:19:25 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 72CAC3A6838 for ; Mon, 23 Nov 2009 03:19:25 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nANBJ2cZ014730; Mon, 23 Nov 2009 13:19:18 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:19:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:19:05 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 23 Nov 2009 12:19:05 +0100 From: To: Date: Mon, 23 Nov 2009 12:19:03 +0100 Thread-Topic: [TLS] simplistic renego protection Thread-Index: Acpofjm6I/gVbPolRaWeyeE33uAXNADsGLfA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310BB2AB@NOK-EUMSG-01.mgdnok.nokia.com> References: <4B0421D0.50509@pobox.com> from "Michael D'Errico" at Nov 18, 9 08:33:20 am <200911181837.nAIIbXJu009133@fs4113.wdf.sap.corp> In-Reply-To: <200911181837.nAIIbXJu009133@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 11:19:05.0501 (UTC) FILETIME=[C487CCD0:01CA6C2E] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 11:19:27 -0000 Martin Rex wrote: > Does anyone remeber that the TLS WG gave the advice to people asking > for identity protection to perform an initial client-anonymous TLS > handshake directly followed by a renegotiation with client-cert > authentication? >=20 > (a related discussion what about gss-api authentication > around 20-dec-2006, Subject: [TLS] Comments on TLS identity > protection) Yes... and as Eric noted, as long as the 2nd handshake "directly follows" (=3Dno application data is exchanged using the first session), this seems to be secure already.... Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Mon Nov 23 03:31:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569083A6A48 for ; Mon, 23 Nov 2009 03:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, 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 U8Ab6Oi6oZau for ; Mon, 23 Nov 2009 03:31:13 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0530B3A68F6 for ; Mon, 23 Nov 2009 03:31:12 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nANBUg9R026044; Mon, 23 Nov 2009 13:31:02 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:30:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:30:49 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 23 Nov 2009 12:30:49 +0100 From: To: , Date: Mon, 23 Nov 2009 12:30:43 +0100 Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acpo77I4519e291ZjkaMOA59EksXQwDP0C/Q Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310BB2C7@NOK-EUMSG-01.mgdnok.nokia.com> References: <4B04F92A.8050903@extendedsubset.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AqTo CsFQ CwT5 EauQ Ef4A HMyM Hj1m H79W LErz Nw41 OO4Z O9AG QaZ1 S5ag S/5W YUUE; 2; cwB0AGUAZgBhAG4AQABhAGEAYQAtAHMAZQBjAC4AYwBvAG0AOwB0AGwAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {DA2C9E77-683F-49C2-B880-F05822D8965C}; cABhAHMAaQAuAGUAcgBvAG4AZQBuAEAAbgBvAGsAaQBhAC4AYwBvAG0A; Mon, 23 Nov 2009 11:30:43 GMT; UgBFADoAIABbAFQATABTAF0AIABQAHIAbwBwAG8AcwBhAGwAIABmAG8AcgAgAGgAeQBiAHIAaQBkACAAcwBvAGwAdQB0AGkAbwBuACAAdQBzAGkAbgBnACAAbQBvAHMAdAAgAG8AZgAgAHQAaABlACAAaQBkAGUAYQBzAA== x-cr-puzzleid: {DA2C9E77-683F-49C2-B880-F05822D8965C} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 11:30:49.0655 (UTC) FILETIME=[683D2C70:01CA6C30] X-Nokia-AV: Clean Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 11:31:14 -0000 Stefan Santesson wrote: > I think we agree that an upgraded finished calculation is not a > dirty hack. This is what future versions of TLS will use by > default. >=20 > Remains then the signaling C->S and S->C client. >=20 > The RI proposal also includes the use of a magic cipher suite, so > that dirty hack is in both proposals. Well.. IMHO the "magic cipher suite" (for client-to-server signalling) is the less ugly part of the hack. The uglier part is the server-to-client signalling. All the proposed methods (new alert, new handshake message, SH.version, SH.random, SH.session_id, SH.cipher_suite, SH.compression_method, "unsolicited" extension, server's Finished, magic server Certificate) seem to "work" (to some degree), but nobody can claim they're pretty. Using TLS extensions is perhaps slightly less ugly, but has other drawbacks (so I wouldn't dismiss the other options just because of "ugliness"). However, it's IMHO good to recognize that when we start comparing "ugliness", we're very much in the domain of subjective design preferences, and the arguments are basically "it could/should be nicer" (even though some recent emails have used phrases like "using X would be wrong" or "X is a bad idea") Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Mon Nov 23 03:35:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B703A67B8 for ; Mon, 23 Nov 2009 03:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 sC6j7oqr85pq for ; Mon, 23 Nov 2009 03:35:54 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 36BA73A67B6 for ; Mon, 23 Nov 2009 03:35:53 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nANBZQhd000496; Mon, 23 Nov 2009 13:35:46 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:35:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:35:43 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 23 Nov 2009 12:35:42 +0100 From: To: , Date: Mon, 23 Nov 2009 12:35:40 +0100 Thread-Topic: [TLS] The Hardware Angle Thread-Index: AcppTKCw93Q0Qqh0Rjm9G//t8pi0XAC4+G5g Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310BB2DB@NOK-EUMSG-01.mgdnok.nokia.com> References: <200911191749.nAJHn2IT001762@fs4113.wdf.sap.corp> <4B0588F7.7090107@drh-consultancy.demon.co.uk> <4B059978.2010800@pobox.com> In-Reply-To: <4B059978.2010800@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 11:35:43.0393 (UTC) FILETIME=[17520910:01CA6C31] X-Nokia-AV: Clean Subject: Re: [TLS] The Hardware Angle X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 11:35:58 -0000 Hmm... If I want to detect the patched status of my servers, probably running Nessus (or other vulnerability scanner -- which I'm running anyway, if I care enough to deploy IDS) would be much simpler than=20 real-time deep packet inspection of TLS handshakes. A busy site could=20 do hundreds (or more) TLS handshakes per second, but I don't need=20 to check the server's status hundred times a second... And if you're running the check only N times a day, then the hardware complexity of an implementation doesn't really matter... (But using DPI to produce a "there's an SSL/TLS server running=20 at this IP:port" list as input for Nessus could make sense.) Best regards,=20 Pasi=20 (not wearing any hats) > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Michael D'Errico > Sent: 19 November, 2009 21:16 > To: tls@ietf.org > Subject: [TLS] The Hardware Angle >=20 > Dr Stephen Henson wrote: > > > > Well in terms of implementation and overhead I'd prefer that the > client knows as > > soon as possible which method to use. >=20 > This is especially true for hardware. >=20 > I don't think anyone would argue that firewall/monitoring devices > will want to detect the patched status of clients and servers. > The non-extension approach to solving this problem is infinitely > better to a hardware engineer. (I design digital hardware circuits > for fun[*] -- yes I know I'm a geek.) >=20 > The hardware for detecting a patched client is just a few lines of > Verilog code: >=20 > wire [7:0] session_id_len =3D client_hello[34]; > wire [7:0] first_cipher_hi =3D client_hello[37+session_id_len]; > wire [7:0] first_cipher_lo =3D client_hello[38+session_id_len]; > wire [15:0] first_cipher =3D {first_cipher_hi, first_cipher_lo}; >=20 > wire patched_client =3D (first_cipher =3D=3D MAGIC_CIPHER_SUITE); >=20 > (I hope I got that right.) >=20 > The hardware for detecting a patched server is similarly easy: >=20 > wire [7:0] major_version =3D server_hello[0]; > wire [7:0] minor_version =3D server_hello[1]; > wire [15:0] server_version =3D {major_version, minor_version}; >=20 > wire patched_server =3D (server_version >=3D 16'h0380); >=20 > This is all purely combinational logic, i.e. it is nearly > instantaneous. >=20 > If our solution involves extensions or altered Certificate messages, > then the hardware becomes many orders of magnitude more difficult. You > require "sequential logic" which means that state machines are needed > to parse through the Hello messages. Many clock cycles will be wasted, > meaning that we will have significantly slowed down all secure Internet > traffic. >=20 > Mike >=20 >=20 > [*] see http://www.digilentinc.com (contact me off-list if interested > in this -- it has made me a much better software developer as well) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Pasi.Eronen@nokia.com Mon Nov 23 04:01:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4143A6A4E for ; Mon, 23 Nov 2009 04:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 REyPkCCOPtKg for ; Mon, 23 Nov 2009 04:01:27 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1A2AD3A6A38 for ; Mon, 23 Nov 2009 04:01:26 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nANC19gw022312; Mon, 23 Nov 2009 14:01:17 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:59:29 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:57:32 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 23 Nov 2009 12:56:59 +0100 From: To: , Date: Mon, 23 Nov 2009 12:56:57 +0100 Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acpr4MuCoH9fgMr+RY+eDKiP6dw7xAAUM/sA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310BB333@NOK-EUMSG-01.mgdnok.nokia.com> References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> In-Reply-To: <4B09ECAB.7050205@bolyard.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 11:57:32.0620 (UTC) FILETIME=[23AE38C0:01CA6C34] X-Nokia-AV: Clean Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 12:01:28 -0000 The duty of the TLS WG (and other IETF working groups) is to "make the Internet work better" [RFC3935]. Since we're doing engineering, not mathematics, we have to deal with the often messy real-world Internet, not the Internet of axiomatic RFCs. So deployability in real world is definitely one important issue that the WG has to consider when fixing this vulnerability. It's not the only important issue, and it's certainly one where different people can legitimately have different opinions. But it's also not something the WG can just ignore. Best regards, Pasi Nelson B Bolyard wrote: =20 > It is the duty of the TLS working group to fix the renegotiation > vulnerability for clients and servers that are already compliant to > any of the existing published RFCs for versions of TLS, and for any > future implementations that will be compliant. >=20 > Some in this list seem to demand that we also must devise a solution > for servers that never did comply to any of the specifications for > any of the versions, not even SSL 3.0, in that they did not ignore > unknown hello extensions, and/or did not properly negotiate any > version of SSL/TLS in the presence of requested versions other than > 3.0. >=20 > Even now, we are hearing requests from purveyors of non-compliant > implementations who wish to remain non-compliant, but wish us to > ensure that we will henceforth define TLS standards to ensure > interoperability with their non-compliant implementations. >=20 > The failures of non-compliant implementations to interoperate with > compliant TLS implementations is not a shortcoming of the IETF TLS > working group. It is not "bad engineering" on the part of the IETF > TLS working group. The fact that some refuse to comply even now > does not, IMO, create a burden of duty on the IETF TLS working group > to devise solutions that can be implemented without requiring > compliance in the implementations. >=20 > As a standards body, we can only provide assurances of > interoperability for implementations that comply to the > specifications that we provide. It is not our duty nor our goal to > provide guarantees of interoperability to those implementations that > have avoided compliance for over a decade. From Pasi.Eronen@nokia.com Mon Nov 23 04:50:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B63428C132 for ; Mon, 23 Nov 2009 04:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9XLT60BDWYIT for ; Mon, 23 Nov 2009 04:50:47 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AA19328C0DB for ; Mon, 23 Nov 2009 04:50:47 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nANCoXnf011162; Mon, 23 Nov 2009 06:50:39 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 14:50:38 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 14:50:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 14:50:28 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 23 Nov 2009 13:50:18 +0100 From: To: , Date: Mon, 23 Nov 2009 13:50:17 +0100 Thread-Topic: Server-only solution - proposed text Thread-Index: AcpsHrQfc2dpXjJbQye8ntQsVgpoVgAHJMXQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB774F310BB3FBNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 12:50:28.0831 (UTC) FILETIME=[88D98EF0:01CA6C3B] X-Nokia-AV: Clean Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 12:50:51 -0000 --_000_808FD6E27AD4884E94820BC333B2DB774F310BB3FBNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Earlier Eric noted that if no application data is exchanged between the ini= tial and renegotiation handshake (i.e. no application data is sent using th= e 1st session), this would be safe even without protocol changes. Should th= is be included in this section, too? Best regards, Pasi (not wearing any hats) From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Y= aron Sheffer Sent: 23 November, 2009 11:24 To: tls@ietf.org Subject: [TLS] Server-only solution - proposed text Hi, Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin's I= -D-to-be) are making changes to the protocol, and therefore will only becom= e effective once a good percentage of clients have been patched. In the mea= ntime, administrators could fix their (patched) servers locally in many cas= es, without waiting for the client population to get fixed. I propose to ad= d the following short section to both drafts: X. Server-Side Mitigation Procedures We assume that it will take a significant amount of time until the protocol= change defined in this document is adopted by all clients. However, in man= y cases a server-only mitigation is possible in the interim: many TLS appli= cations, and in particular, many Web (HTTPS) applications, do not require r= enegotiation for proper operation. Implementations of the current document = (unless they employ a strict policy, allowing only protected clients to con= nect) SHOULD be configurable to disallow TLS renegotiation with vulnerable = clients. The following three settings are RECOMMENDED: - Allow any renegotiation with unprotected clients. - Allow only server-initiated renegotiation with unprotected clients. - Disallow renegotiation with unprotected clients.. The default setting is a matter of vendor and/or local policy. [Note: this contradicts the sentence "Servers SHOULD NOT allow clients to r= enegotiate without using this extension" in the Security Considerations of = draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be foll= owed by many implementers.] Thanks, Yaron --_000_808FD6E27AD4884E94820BC333B2DB774F310BB3FBNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Earlier Eric noted that if no application data is exchanged between the initial and renegotiation handshake (i.e. no application data i= s sent using the 1st session), this would be safe even without protocol chang= es. Should this be included in this section, too?

 

Best regards,

Pasi

(not wearing any hats)

 

From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Yaron Sheffer
Sent: 23 November, 2009 11:24
To: tls@ietf.org
Subject: [TLS] Server-only solution - proposed text

 

Hi,

 

Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin’s = I-D-to-be) are making changes to the protocol, and therefore will only become effectiv= e once a good percentage of clients have been patched. In the meantime, administrators could fix their (patched) servers locally in many cases, wit= hout waiting for the client population to get fixed. I propose to add the follow= ing short section to both drafts:

 

X. Server-Side Mitigation Procedures

 

We assume that it will take a significant amount of time until the protocol ch= ange defined in this document is adopted by all clients. However, in many cases = a server-only mitigation is possible in the interim: many TLS applications, a= nd in particular, many Web (HTTPS) applications, do not require renegotiation = for proper operation. Implementations of the current document (unless they empl= oy a strict policy, allowing only protected clients to connect) SHOULD be config= urable to disallow TLS renegotiation with vulnerable clients. The following three settings are RECOMMENDED:

 

-       Allow any renegotiation with unprotected clients.

-       Allow only server-initiated renegotiation with unprotected clients.

-       Disallow renegotiation with unprotected clients..

 

The default setting is a matter of vendor and/or local policy.

 

[Note: this contradicts the sentence “Servers SHOULD NOT allow clients to re= negotiate without using this extension” in the Security Considerations of draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be foll= owed by many implementers.]

 

Thanks,

          &nb= sp; Yaron

--_000_808FD6E27AD4884E94820BC333B2DB774F310BB3FBNOKEUMSG01mgd_-- From yngve@opera.com Mon Nov 23 05:28:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A423A6A70 for ; Mon, 23 Nov 2009 05:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 s4A2widZ6LC8 for ; Mon, 23 Nov 2009 05:28:39 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 12C633A6861 for ; Mon, 23 Nov 2009 05:28:38 -0800 (PST) Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nANDQx6N007552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Nov 2009 13:27:00 GMT Date: Mon, 23 Nov 2009 14:28:27 +0100 To: "Joseph Salowey (jsalowey)" , tls@ietf.org From: "Yngve Nysaeter Pettersen" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.65 (Win32) Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: yngve@opera.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:28:40 -0000 On Fri, 20 Nov 2009 22:53:27 +0100, Joseph Salowey (jsalowey) wrote: > We have had a lot of good discussion on this list, but I think we need > to start converging on a solution. As I said in a previous message, I've > asked Eric to serve as editor for the WG draft and he has posted > draft-ietf-tls-renegotiation-00 as a starting point. I realize that > there are a number of people who aren't happy with aspects of the draft, > or indeed with the draft as a whole, but I'd like to get the sense for > the feelings of the group as a whole. If we have rough consensus that > this is a workable approach, we can try to nail down the remaining > issues and move forward. > > To try to keep this concrete, please respond with answers to this > question: > > Support for the draft: > - I support this draft > - I support this draft with the following modification I support this draft I may also support a signaling mechanisms that can patch older non-extension implementations of SSLv3 and TLS, provided a "good enough" solution can be found, but I do not think the search for such a mechanism should delay this draft. (I am also inclined to agree with Nelson B. Bolyard that it is time to stop being nice to non-compliant servers regarding extension intolerance and incorrect version negotiation; we just need a date for when the support is turned off) I also think the finished document should include a timeline for when lenient implementations should become strict, and refuse to negotiate with unpatched peers. Without such a timeline I think it will take much longer to get rid of unpatched implementations (particularly servers) than is necessary to get this problem removed from the net. IMO such a timeline should not be longer than 12 months from the publication of the RFC. Leaving the decision for such a sunset date to vendors is not a good idea (just look how long SSLv2 and export ciphers were supported, mostly because a few major internet services refused to upgrade). -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From yaronf@checkpoint.com Mon Nov 23 05:48:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F6728C0EE for ; Mon, 23 Nov 2009 05:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wS7i90nT9yT for ; Mon, 23 Nov 2009 05:48:50 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id B71F53A65A5 for ; Mon, 23 Nov 2009 05:48:49 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nANDmiGo016949; Mon, 23 Nov 2009 15:48:44 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 23 Nov 2009 15:48:49 +0200 From: Yaron Sheffer To: "Pasi.Eronen@nokia.com" , "tls@ietf.org" Date: Mon, 23 Nov 2009 15:48:49 +0200 Thread-Topic: Server-only solution - proposed text Thread-Index: AcpsHrQfc2dpXjJbQye8ntQsVgpoVgAHJMXQAAChQ8A= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B294@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B294ilex01adche_" MIME-Version: 1.0 Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:48:55 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B294ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pasi, To clarify, are you proposing to add a vendor or an administrator requireme= nt. That is: is the vendor supposed to detect these situations and allow re= negotiation, even when a strict server is accessed by an unpatched client? = Or do you expect the administrator to understand their application well eno= ugh to configure the server leniently in this case? I consider the latter a= bit of a stretch. Thanks, Yaron ________________________________ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Monday, November 23, 2009 14:50 To: Yaron Sheffer; tls@ietf.org Subject: RE: Server-only solution - proposed text Earlier Eric noted that if no application data is exchanged between the ini= tial and renegotiation handshake (i.e. no application data is sent using th= e 1st session), this would be safe even without protocol changes. Should th= is be included in this section, too? Best regards, Pasi (not wearing any hats) From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Y= aron Sheffer Sent: 23 November, 2009 11:24 To: tls@ietf.org Subject: [TLS] Server-only solution - proposed text Hi, Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin's I= -D-to-be) are making changes to the protocol, and therefore will only becom= e effective once a good percentage of clients have been patched. In the mea= ntime, administrators could fix their (patched) servers locally in many cas= es, without waiting for the client population to get fixed. I propose to ad= d the following short section to both drafts: X. Server-Side Mitigation Procedures We assume that it will take a significant amount of time until the protocol= change defined in this document is adopted by all clients. However, in man= y cases a server-only mitigation is possible in the interim: many TLS appli= cations, and in particular, many Web (HTTPS) applications, do not require r= enegotiation for proper operation. Implementations of the current document = (unless they employ a strict policy, allowing only protected clients to con= nect) SHOULD be configurable to disallow TLS renegotiation with vulnerable = clients. The following three settings are RECOMMENDED: - Allow any renegotiation with unprotected clients. - Allow only server-initiated renegotiation with unprotected clients. - Disallow renegotiation with unprotected clients.. The default setting is a matter of vendor and/or local policy. [Note: this contradicts the sentence "Servers SHOULD NOT allow clients to r= enegotiate without using this extension" in the Security Considerations of = draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be foll= owed by many implementers.] Thanks, Yaron --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B294ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pasi,

 

To clarify, are you proposing to add a vendor or an administrator requirement. That is: is the vendor supposed to detect these situations and allow renegotiation, even when a strict server = is accessed by an unpatched client? Or do you expect the administrator to understand th= eir application well enough to configure the server leniently in this case? I consider the latter a bit of a stretch.

 

Thanks,

      &n= bsp;     Yaron

 

From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Monday, November 23, 2= 009 14:50
To: Yaron Sheffer; tls@ietf.org
Subject: RE: Server-only sol= ution - proposed text

 

Earlier Eric n= oted that if no application data is exchanged between the initial and renegotiat= ion handshake (i.e. no application data is sent using the 1st session), this wo= uld be safe even without protocol changes. Should this be included in this sect= ion, too?

 

Best regards,<= o:p>

Pasi

(not wearing a= ny hats)

 

From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Yaron Sheffer=
Sent: 23 November, 2009 11:2= 4
To: tls@ietf.org
Subject: [TLS] Server-only s= olution - proposed text

 

Hi,

 

Both proposals on the table (draft-ietf-tls-renegotiatio= n-00 and Martin’s I-D-to-be) are making changes to the protocol, and there= fore will only become effective once a good percentage of clients have been patc= hed. In the meantime, administrators could fix their (patched) servers locally i= n many cases, without waiting for the client population to get fixed. I propo= se to add the following short section to both drafts:=

 

X. Server-Side Mitigation Procedures

 

We assume that it will take a significant amount of time until the protocol change defined in this document is adopted by all client= s. However, in many cases a server-only mitigation is possible in the interim: many TLS applications, and in particular, many Web (HTTPS) applications, do= not require renegotiation for proper operation. Implementations of the current document (unless they employ a strict policy, allowing only protected clien= ts to connect) SHOULD be configurable to disallow TLS renegotiation with vulnerable clients. The following three settings are RECOMMENDED:

 

-       Allow any renegotiation with unprotected clients.

-       Allow only server-initiated renegotiation with unprotected clients.<= /font>

-       Disallow renegotia= tion with unprotected clients..

 

The default setting is a matter of vendor and/or local policy.

 

[Note: this contradicts the sentence “Servers SHOU= LD NOT allow clients to renegotiate without using this extension” in the Security Considerations of draft-ietf-tls-renegotiation-00, which unfortuna= tely is unlikely to be followed by many implementers.]<= /p>

 

Thanks,

         &n= bsp;  Yaron

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B294ilex01adche_-- From Pasi.Eronen@nokia.com Mon Nov 23 05:56:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E523A68B0 for ; Mon, 23 Nov 2009 05:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Ph1m+7-MXLPm for ; Mon, 23 Nov 2009 05:56:51 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6CEFE3A67D4 for ; Mon, 23 Nov 2009 05:56:50 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nANDuLlN022455; Mon, 23 Nov 2009 15:56:40 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 15:56:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 15:56:23 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 23 Nov 2009 14:56:22 +0100 From: To: , Date: Mon, 23 Nov 2009 14:56:21 +0100 Thread-Topic: Server-only solution - proposed text Thread-Index: AcpsHrQfc2dpXjJbQye8ntQsVgpoVgAHJMXQAAChQ8AAAZ3y8A== Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310BB4F3@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B294@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B294@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB774F310BB4F3NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 13:56:23.0117 (UTC) FILETIME=[BDC9B7D0:01CA6C44] X-Nokia-AV: Clean Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:56:56 -0000 --_000_808FD6E27AD4884E94820BC333B2DB774F310BB4F3NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaron, I was proposing a mitigation for the server TLS library implementation (not= administrator) -- if it hasn't received any application data before renego= tiation, it could allow renegotiation (and if "interleaved" application da= ta is received during the renegotiation handshake, tear down the connection= ). (I don't think this can be correctly done by the application in most cases,= especially since you could receive application data during the renegotiati= on handshake.) Best regards, Pasi (not wearing any hats) From: ext Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: 23 November, 2009 15:49 To: Eronen Pasi (Nokia-NRC/Helsinki); tls@ietf.org Subject: RE: Server-only solution - proposed text Hi Pasi, To clarify, are you proposing to add a vendor or an administrator requireme= nt. That is: is the vendor supposed to detect these situations and allow re= negotiation, even when a strict server is accessed by an unpatched client? = Or do you expect the administrator to understand their application well eno= ugh to configure the server leniently in this case? I consider the latter a= bit of a stretch. Thanks, Yaron ________________________________ From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Monday, November 23, 2009 14:50 To: Yaron Sheffer; tls@ietf.org Subject: RE: Server-only solution - proposed text Earlier Eric noted that if no application data is exchanged between the ini= tial and renegotiation handshake (i.e. no application data is sent using th= e 1st session), this would be safe even without protocol changes. Should th= is be included in this section, too? Best regards, Pasi (not wearing any hats) From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Y= aron Sheffer Sent: 23 November, 2009 11:24 To: tls@ietf.org Subject: [TLS] Server-only solution - proposed text Hi, Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin's I= -D-to-be) are making changes to the protocol, and therefore will only becom= e effective once a good percentage of clients have been patched. In the mea= ntime, administrators could fix their (patched) servers locally in many cas= es, without waiting for the client population to get fixed. I propose to ad= d the following short section to both drafts: X. Server-Side Mitigation Procedures We assume that it will take a significant amount of time until the protocol= change defined in this document is adopted by all clients. However, in man= y cases a server-only mitigation is possible in the interim: many TLS appli= cations, and in particular, many Web (HTTPS) applications, do not require r= enegotiation for proper operation. Implementations of the current document = (unless they employ a strict policy, allowing only protected clients to con= nect) SHOULD be configurable to disallow TLS renegotiation with vulnerable = clients. The following three settings are RECOMMENDED: - Allow any renegotiation with unprotected clients. - Allow only server-initiated renegotiation with unprotected clients. - Disallow renegotiation with unprotected clients.. The default setting is a matter of vendor and/or local policy. [Note: this contradicts the sentence "Servers SHOULD NOT allow clients to r= enegotiate without using this extension" in the Security Considerations of = draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be foll= owed by many implementers.] Thanks, Yaron --_000_808FD6E27AD4884E94820BC333B2DB774F310BB4F3NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yaron,

 

I was proposing a mitigation for the server TLS library implementation (not administrator) -- if it hasn't received any application data before renegotiation,  it could allow renegotiation (and if "interleaved" application data is received during the renegotiati= on handshake, tear down the connection).

 

(I don't think this can be correctly done by the application= in most cases, especially since you could receive application data during the = renegotiation handshake.)

 

Best regards,

Pasi

(not wearing any hats)

 

From: ext Yaron She= ffer [mailto:yaronf@checkpoint.com]
Sent: 23 November, 2009 15:49
To: Eronen Pasi (Nokia-NRC/Helsinki); tls@ietf.org
Subject: RE: Server-only solution - proposed text<= /p>

 

Hi Pasi,

 

To clarify, are you proposing to add a vendor or an administrat= or requirement. That is: is the vendor supposed to detect these situations and allow renegotiation, even when a strict server is accessed by an unpatched client? Or do you expect the administrator to understand their application = well enough to configure the server leniently in this case? I consider the latte= r a bit of a stretch.

 

Thanks,

          &nb= sp; Yaron

 

From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Monday, November 23, 2009 14:50
To: Yaron Sheffer; tls@ietf.org
Subject: RE: Server-only solution - proposed text<= /p>

 

Earlier Eric noted that if no application data is exchanged between the initial and renegotiation handshake (i.e. no application data i= s sent using the 1st session), this would be safe even without protocol chang= es. Should this be included in this section, too?

 

Best regards,

Pasi

(not wearing any hats)

 

From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Yaron Sheffer
Sent: 23 November, 2009 11:24
To: tls@ietf.org
Subject: [TLS] Server-only solution - proposed text

 

Hi,

 

Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin’s = I-D-to-be) are making changes to the protocol, and therefore will only become effectiv= e once a good percentage of clients have been patched. In the meantime, administrators could fix their (patched) servers locally in many cases, wit= hout waiting for the client population to get fixed. I propose to add the follow= ing short section to both drafts:

 

X. Server-Side Mitigation Procedures

 

We assume that it will take a significant amount of time until the protocol ch= ange defined in this document is adopted by all clients. However, in many cases = a server-only mitigation is possible in the interim: many TLS applications, a= nd in particular, many Web (HTTPS) applications, do not require renegotiation = for proper operation. Implementations of the current document (unless they empl= oy a strict policy, allowing only protected clients to connect) SHOULD be configurable to disallow TLS renegotiation with vulnerable clients. The following three settings are RECOMMENDED:

 

-       Allow any renegotiation with unprotected clients.

-       Allow only server-initiated renegotiation with unprotected clients.

-       Disallow renegotiation with unprotected clients..

 

The default setting is a matter of vendor and/or local policy.

 

[Note: this contradicts the sentence “Servers SHOULD NOT allow clients to re= negotiate without using this extension” in the Security Considerations of draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be foll= owed by many implementers.]

 

Thanks,

          &nb= sp; Yaron

--_000_808FD6E27AD4884E94820BC333B2DB774F310BB4F3NOKEUMSG01mgd_-- From mrex@sap.com Mon Nov 23 07:57:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE9C3A691C for ; Mon, 23 Nov 2009 07:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.127, 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 QoGQE7y9VpkC for ; Mon, 23 Nov 2009 07:57:24 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D11FA3A68CB for ; Mon, 23 Nov 2009 07:57:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nANFvIH5008371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 16:57:18 +0100 (MET) From: Martin Rex Message-Id: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Mon, 23 Nov 2009 16:57:18 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Subject: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 15:57:24 -0000 I have just submitted my proposal (I-D) to the IETF datatracker. http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt -Martin From mrex@sap.com Mon Nov 23 08:34:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100733A689C for ; Mon, 23 Nov 2009 08:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.125, 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 OvrKqg8ZulOb for ; Mon, 23 Nov 2009 08:34:48 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 0466E3A6843 for ; Mon, 23 Nov 2009 08:34:47 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nANGYZ7I019647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 17:34:35 +0100 (MET) From: Martin Rex Message-Id: <200911231634.nANGYYWE009232@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Mon, 23 Nov 2009 17:34:34 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Nov 23, 9 06:03:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 16:34:49 -0000 Peter Gutmann wrote: > > Michael Stone writes: > > >For example, the "Client Browser Requirements" section of the US DISA's > >guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that > >must be enabled and disabled. Similarly, it seems likely that many contracts > >have been written which mandate the use of FIPS 140-2-approved ciphers, e.g., > >in order to establish compliance with the vague PCI-DSS "strong cryptography" > >requirement. > > Does it say "ciphers" or "cipher suites"? This isn't enabling (or disabling) > any ciphers at all, so it would seem to be excluded from the restrictions. The use of a "special cipher suite ID" for signaling is entirely independent from cipher suites that are enabled or disabled on clients and servers. It is only an ID, it does not represent a real cipher suites, is assigned from the managed number space of cipher suite IDs so that it can not be confused with real cipher suites, is recommended to be not configurable by and not be visible to the regular ciphersuite configuration APIs and UIs, and ist MUST NOT be selected by the server as a common cipher suite. > > (In any case if cipher suites really are explicitly restricted, you could > always signal via compression algorithms). *I* don't know the interoperability of compressions with the installed base, but since that field had used with only a single element and value for several years, there might be a problem. Pasi's comment on compression algorithm identifiers is here: http://www.ietf.org/mail-archive/web/tls/current/msg04140.html -Martin From mrex@sap.com Mon Nov 23 08:44:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C172D3A6A4F for ; Mon, 23 Nov 2009 08:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.128 X-Spam-Level: X-Spam-Status: No, score=-104.128 tagged_above=-999 required=5 tests=[AWL=2.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 ZjckO47X0rcq for ; Mon, 23 Nov 2009 08:44:07 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 987B73A698D for ; Mon, 23 Nov 2009 08:44:06 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nANGi1XW003083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 17:44:01 +0100 (MET) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com From: Internet-Drafts@ietf.org Orig-To: i-d-announce@ietf.org To: tls@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091123160002.1F44B3A6A7D@core3.amsl.com> Date: Mon, 23 Nov 2009 08:00:02 -0800 (PST) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Sender: mrex@sap.com Errors-To: i-d-announce-bounces@ietf.org X-Scanner: Virus Scanner virwal06 X-Scanner: Virus Scanner virwal03 X-SAP: out Subject: [TLS] I-D Action:draft-mrex-tls-secure-renegotiation-00.txt X-BeenThere: tls@ietf.org Reply-To: internet-drafts@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 16:44:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transport Layer Security (TLS) Secure Renegotiation Author(s) : M. Rex Filename : draft-mrex-tls-secure-renegotiation-00.txt Pages : 15 Date : 2009-11-23 A protocol design flaw in the TLS renegotiation handshake leaves all currently implemented protocol version of TLS (SSLv3 to TLSv1.2) vulnerable to Man-in-the-Middle (MitM) attacks where the attacker can establish a TLS session with a server, send crafted application data of his choice to the server and then proxy an unsuspecting client's TLS handshake into the TLS renegotiation handshake of the server. The application on top of TLS sees the data injected by the attacker and the data sent by the client as a single data stream and assumes that an authentication during the TLS renegotiation handshake or contained in the application data from the client applies to the entire data stream received through the TLS-protected communication channel. This document describes a protocol change for all protocol versions of TLS plus SSLv3 that will fix this vulnerability for all communication between updated TLS clients and updated TLS servers. IMPORTANT: _All_ existing implementations of TLS and SSLv3 will have to be updated, including those that have TLS renegotiation disabled and even those that do not implement TLS renegotiation at all! A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mrex-tls-secure-renegotiation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-mrex-tls-secure-renegotiation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-23075242.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From mrex@sap.com Mon Nov 23 09:30:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284E73A6AAC for ; Mon, 23 Nov 2009 09:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.123, 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 Tim072RY7S59 for ; Mon, 23 Nov 2009 09:30:13 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2E1C53A6914 for ; Mon, 23 Nov 2009 09:30:12 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nANHU5Ld000058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 18:30:05 +0100 (MET) From: Martin Rex Message-Id: <200911231730.nANHU4oZ012649@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Mon, 23 Nov 2009 18:30:04 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310BB4F3@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 23, 9 02:56:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org, yaronf@checkpoint.com Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:30:14 -0000 Pasi.Eronen@nokia.com wrote: > > I was proposing a mitigation for the server TLS library implementation > (not administrator) -- if it hasn't received any application data > before renegotiation, it could allow renegotiation (and if > "interleaved" application data is received during the renegotiation > handshake, tear down the connection). > > (I don't think this can be correctly done by the application in most > cases, especially since you could receive application data during > the renegotiation handshake.) That observation about app data interleaved with the renegotiation is significant! This could be a conceivable backwards interoperability scenario for updated servers with old clients that can not be upgraded for whatever reason and use the renegotiation without prior app-data exchange only for purposes like client identity protection. The more common use case with HTTP over TLS and on-demand authentication through TLS renegotiate (ab)uses the possibility to send app data over the initial connection and let the server decide whether to request client authentication after having seen the request. To me, it looks like the only good advice for the latter is to get server and clients updated as soon as humanely possible and disable old renegotiation completely on the server. -Martin From lists@drh-consultancy.demon.co.uk Mon Nov 23 09:50:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5393A67F7 for ; Mon, 23 Nov 2009 09:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvOHPDJG3r7A for ; Mon, 23 Nov 2009 09:50:07 -0800 (PST) Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by core3.amsl.com (Postfix) with ESMTP id 5CD8E3A67EA for ; Mon, 23 Nov 2009 09:50:07 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:52416 helo=[192.168.7.8]) by relay00.mail.eu.clara.net (relay.clara.net [213.253.3.40]:10587) with esmtpa (authdaemon_plain:drh) id 1NCd34-0006pj-08 (Exim 4.69) for tls@ietf.org (return-path ); Mon, 23 Nov 2009 17:50:02 +0000 Message-ID: <4B0ACB4A.8060404@drh-consultancy.demon.co.uk> Date: Mon, 23 Nov 2009 17:50:02 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911231634.nANGYYWE009232@fs4113.wdf.sap.corp> In-Reply-To: <200911231634.nANGYYWE009232@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:50:09 -0000 Martin Rex wrote: > Peter Gutmann wrote: > >> (In any case if cipher suites really are explicitly restricted, you could >> always signal via compression algorithms). > > *I* don't know the interoperability of compressions with the installed > base, but since that field had used with only a single element and > value for several years, there might be a problem. > They can't be used with SSLv2 compatible client hellos btw. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Mon Nov 23 10:27:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843A43A695B for ; Mon, 23 Nov 2009 10:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 TuWove7X82Qi for ; Mon, 23 Nov 2009 10:27:54 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 1CF493A680C for ; Mon, 23 Nov 2009 10:27:53 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nANIRiQn009504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 19:27:44 +0100 (MET) From: Martin Rex Message-Id: <200911231827.nANIRhLD016109@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Mon, 23 Nov 2009 19:27:43 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Nov 23, 9 09:33:31 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:27:55 -0000 Stefan Santesson wrote: > > Could you elaborate on this? > > I've looked through the SSLv3 spec and couldn't find any evidence that > support this claim. > > > On 09-11-23 3:00 AM, "Nelson B Bolyard" wrote: > > > That also applies to specification compliant SSL 3.0 servers, which were > > always supposed to ignore extra data in the client hellos. > > It seems to me that the original client hello syntax was defined without > extensibility. Looking at the available documents http://tools.ietf.org/html/draft-freier-ssl-version3-00 http://tools.ietf.org/html/draft-freier-ssl-version3-01 http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 it seems to be evident that the original protocol design from Netscape did *NOT* contain forward extensibility for the ClientHello handshake message. The document which I have been refering to as SSLv3 most of the time (draft-ietf-tls-ssl-version3-00.txt) contains such a forward compatibility notice -- however it was never published by the IETF as an informational RFC. When I looked at www.netscape.com in 2000-2002 and used their site search, it directed me to an old version of the spec. I did find the draft-ietf-tls-ssl-version3-00 document only from searching the TLS mailing list archives, where the document had been posted in its entirety. Now, I see the following problems with this: - The forward interoperability provision in ClientHello was added when there already was a significant installed base that did not include the forward interoperability on a ClientHello extension - The TLS WG never cared to get an updated SSLv3 spec published and publicly available that contained the forward interoperability provision in ClientHello At that time, I-Ds were deleted from the repository after 6 month! - If you were searching for an SSLv3 spec at Netscape, you were usually directed to a pretty HTML&Postscript version of an older version of the spec without the forward interoperability provision. URL from 2005: http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM - The TLS WG defined TLS extensions long after TLSv1.0 and didn't do all that much since then in order to determine the scope of the interoperability problem and solutions to improve the situation. There were some efforts by individuals or vendors, but it does not seem that TLS WG saw it as a sufficiently interesting problem to care about. What I think is funny here: the first I-D from freier (12/95) contains this: C. Version 2.0 Backward Compatibility Version 3.0 clients that support Version 2.0 servers must send Version 2.0 client hello messages [SSL-2]. Version 3.0 servers should accept either client hello format. The only deviations from the Version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec. Warning: The ability to send Version 2.0 client hello messages will be phased out with all due haste. Implementors should make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for transitioning to newer versions. Compare this to TLSv1.2 RFC-5246: E.2. Compatibility with SSL 2.0 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST contain the same version number as would be used for ordinary ClientHello, and MUST encode the supported TLS cipher suites in the CIPHER-SPECS-DATA field as described below. Warning: The ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste, since the newer ClientHello format provides better mechanisms for moving to newer versions and negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. Which essentially means that TLSv1.2 still plans to phase out SSL Version2 ClientHello -- but had not started to do so yet when TLSv1.2 was published (August 2008). -Martin From djhopwood@googlemail.com Mon Nov 23 11:29:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D3F3A69E9 for ; Mon, 23 Nov 2009 11:29:12 -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 yFCpI2H987h7 for ; Mon, 23 Nov 2009 11:29:11 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 213873A68E9 for ; Mon, 23 Nov 2009 11:29:10 -0800 (PST) Received: by ewy6 with SMTP id 6so2286506ewy.29 for ; Mon, 23 Nov 2009 11:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=ydk/4vvt9kFoYAXIUjxBI5nPpoORQUmEGZcuPn0tnbo=; b=qY0mbg9KuG+f7gWenpuRA+G6viezylzIS8nTjI3h75NnSHkFJXYC8PG3O0hMhIZ6Yd zyhkT6c9Bg4AeKzHc/nFPoQ6s+NFtqCI/SA7joLcKG8KSWm4a4M2kKbdnD1e+6HjHbUh +OCtdqdvM7AiFc8ovVtT/KfQ7xkIXHLZtVWa8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=AE+cuah32V99YtPjm0M87xYcu6xVuv2vJIBvDPyom2Jpj8L9q4pxqq9z/FPpWBIhD5 2mhH9Rk7zIk1RXh/fWCDTsg1ADc1otaeNEmkk9yjOkYHMz9SaFYbxx6fqfKjJ55S/kAM zmdXXu0c9BO00vSa0NROLVE+T2XcoNgMD3kTM= Received: by 10.213.24.9 with SMTP id t9mr3989742ebb.92.1259004540824; Mon, 23 Nov 2009 11:29:00 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 13sm531852ewy.1.2009.11.23.11.28.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 11:29:00 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0AE27C.4010506@jacaranda.org> Date: Mon, 23 Nov 2009 19:29:00 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig27C6DD6D33B619D8D65AC35D" Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:29:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27C6DD6D33B619D8D65AC35D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yaron Sheffer wrote: > Hi, >=20 > Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin= 's I-D-to-be) are making changes to the protocol, and therefore will only= become effective once a good percentage of clients have been patched. In= the meantime, administrators could fix their (patched) servers locally i= n many cases, without waiting for the client population to get fixed. I p= ropose to add the following short section to both drafts: >=20 > X. Server-Side Mitigation Procedures >=20 > We assume that it will take a significant amount of time until the prot= ocol change defined in this document is adopted by all clients. However, = in many cases a server-only mitigation is possible in the interim: many T= LS applications, and in particular, many Web (HTTPS) applications, do not= require renegotiation for proper operation. Implementations of the curre= nt document (unless they employ a strict policy, allowing only protected = clients to connect) SHOULD be configurable to disallow TLS renegotiation = with vulnerable clients. The following three settings are RECOMMENDED: >=20 > - Allow any renegotiation with unprotected clients. > - Allow only server-initiated renegotiation with unprotected clie= nts. > - Disallow renegotiation with unprotected clients.. >=20 > The default setting is a matter of vendor and/or local policy. >=20 > [Note: this contradicts the sentence "Servers SHOULD NOT allow clients = to renegotiate without using this extension" in the Security Consideratio= ns of draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to= be followed by many implementers.] I disagree -- it is entirely reasonable and necessary for servers to disable renegotiation with unpatched clients immediately. In any case, the proposed text above is misleading, since it gives the impression that a connection that is seen as a renegotiation by the server, actually is a renegotiation on the client side. In fact it may be an instance of the attack, and there's no way for the server to know that. In other words, allowing renegotiations with unpatched clients is not fixing the security flaw, it is just dumping the responsibility for fixing it onto the clients. Under the assumption that "it will take a significant amount of time until the protocol change defined in this document is adopted by all clients", that is an unreasonable thing to do. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig27C6DD6D33B619D8D65AC35D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksK4oMACgkQWUc8YzyzqAe++QEAickdIJlf8blpixtfBNjTIei3 ln68FX9JD+TraJl5NxEA/0P0T1+HteKkWOKaVIHv8NBQSC1cMFh4HhdDKoo1ewux =vs1K -----END PGP SIGNATURE----- --------------enig27C6DD6D33B619D8D65AC35D-- From mrex@sap.com Mon Nov 23 11:40:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1983A6AC1 for ; Mon, 23 Nov 2009 11:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 V-InlaGKg8zV for ; Mon, 23 Nov 2009 11:40:15 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 1B8B13A6ABF for ; Mon, 23 Nov 2009 11:40:14 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nANJe9lT000705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 20:40:09 +0100 (MET) From: Martin Rex Message-Id: <200911231940.nANJe9kk020588@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Mon, 23 Nov 2009 20:40:09 +0100 (MET) In-Reply-To: <4B0A3D59.2060508@jacaranda.org> from "David-Sarah Hopwood" at Nov 23, 9 07:44:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:40:16 -0000 David-Sarah Hopwood wrote: > > There is no evidence that this kind of bug currently affects more > than a tiny minority of server implementations. Note that in > , > a single server/frontend implementation -- Lotus Domino WebSphere -- > is implicated in four of the six examples given (A2, A3, A4, and A5). > > However, WebSphere was fixed to be TLS-tolerant in version 5.0.9, > which was released no later than 2002 (the fix is mentioned here: > ). You entirely ignore that this was a real world test performed in 2006! A.2. SSL v3 server refuses TLS 1.0 client (case 2) Date: April 5, 2006 Server: Lotus-Domino/5.0.8 Site: https://www.ecbanking.com.my/ We can not shut down the internet while people are individually deploy patches at various times. > > If we try to connect to each of those sites mentioned in that bug, > the ones that still exist *all* have certificates with domain name > mismatches. Therefore, connections to those servers are vulnerable > to a MITM attack, and it would be correct to refuse to interoperate > with them for that reason. I do not agree with these conclusions. - the sites have moved to different hostnames, and you can connect them perfectly fine with the hostname they use in their certs. Businesses rename all the time due to Marketing "requirements", and the admins are simply trying to be nice to their colleagues (e.g. keep Email-Addresses working) which might be the reason why the DNS-Entry redirects you. - there is no MITM at the TLS level when a server uses a certificate that does not match the hostname that the application used to establish the network connection. Server Endpoint identification is entirely an apps thing (e.g. HTTP over TLS [RFC2818])!! RFC 5246 1. Introduction (last paragraph, top of page 5): The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. Btw. the server endpoint identification in HTTP over TLS is extremely weak, and if the HTTPS-Urls are served through HTTP-pages like with 98% of the use-cases, the quality of that authentication is realllllly weak. > > For clients that don't already have a fallback, OTOH, I can see no > good rationale for adding one. This issue should not be considered an > obstacle to solutions to the renegotiation flaw that use extensions. Those clients that send extensions by default seem to have added app-level reconnect fallbacks for extension-less ClientHellos. If there were no use-cases, these would not have been added. So the alternatives currently are: 1) - submit a TLS fix with the highest possible interoperability (i.e. extension-less) 2) - submit a TLS fix based on extensions - submit apps-fixes to disable fallbacks because of downgrade attacks realize that there are interop problems that can not be ignored - revert the apps-fixes, re-enable fallbacks - submit a different TLS fix without extensions to fix the downgrade attacks Approach (2) involes a huge risk. It may cost a lot of people a lot of time and money and we might end up having to support two different solutions for the same problem in parallel because of the installed base created by the first fix shipment. And then we will have security problems because shipments of the first fix will not security interoperate with shipments of the second fix, i.e. we would create yet another installed base, just that it is much newer and therefore much harder to get them to install the second fix -- especially considering that we would then have fouled up the first one so badly. -Martin From mrex@sap.com Mon Nov 23 11:49:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA353A6AC0 for ; Mon, 23 Nov 2009 11:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 076jmzr28vbL for ; Mon, 23 Nov 2009 11:49:35 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 878963A6ABF for ; Mon, 23 Nov 2009 11:49:35 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nANJnToT026618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 20:49:29 +0100 (MET) From: Martin Rex Message-Id: <200911231949.nANJnTTx021289@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Mon, 23 Nov 2009 20:49:29 +0100 (MET) In-Reply-To: <4B0A3E70.4070603@jacaranda.org> from "David-Sarah Hopwood" at Nov 23, 9 07:49:04 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:49:36 -0000 David-Sarah Hopwood wrote: > > > > Cipher suites, as far as I can tell. Both SSLv2 and SSLv3 are > > mandatory, and TLS is not allowed (if you view the list of protocols > > as exhaustive). > > Then it's mandating insecurity. Why would you want to follow this guidance? Maybe because you are a government agency and that "guidance" is not a suggestion, but a mandatory-to-comply regulation? http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf They allow only ciphersuites with RC4-128 or 3DES, so does not seem to be a downgrade attack involved, even with SSLv2. -Martin From djhopwood@googlemail.com Mon Nov 23 12:07:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0563A69D0 for ; Mon, 23 Nov 2009 12:07:10 -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 oNZGcK10vs8c for ; Mon, 23 Nov 2009 12:07:09 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 1C6B73A692B for ; Mon, 23 Nov 2009 12:07:04 -0800 (PST) Received: by ewy6 with SMTP id 6so2326676ewy.29 for ; Mon, 23 Nov 2009 12:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=KeHmZsFGcqk0DX+JYm3sRy3kOQ0ZP9wcjWkN12277cY=; b=Qi7EI9IuPRdULCGvNtryET4tpslIitu8KCwUI7J2zV/oHgPAvrPyGnpLLLJiUBd4bR LxLDsIv/aJnY17dLM0UbXW/UMfZPE6S/G4DJK4wXD6pFM6sYpuefuynGmTOnVPCy0xwf spgP2pXh5Dqhusv+9XMcAeW9E2zhVfI8lmkec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=AFelJA8TI3Ry1rV/RJU3qh2ifkcntvH7w4S0nA6WiPQiLzAhZYIxUJBy46v67vKUEk f8gVRnfpjlm521issywLZOwEtlu0NM20TKpGMHIVm9N83MemdebTi0IJtcUxzJqx/rAT zQTuGm0JTLfIWQD5jKx5px0E8NwvYL3jsSe6c= Received: by 10.213.100.138 with SMTP id y10mr5254698ebn.96.1259006815166; Mon, 23 Nov 2009 12:06:55 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 7sm1579349eyb.34.2009.11.23.12.06.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 12:06:53 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0AEB53.1020702@jacaranda.org> Date: Mon, 23 Nov 2009 20:06:43 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> <4B09FC30.4070107@bolyard.me> <64E272FB-7420-4B6A-B649-38487A539EF5@checkpoint.com> In-Reply-To: <64E272FB-7420-4B6A-B649-38487A539EF5@checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFD01BAF11B61B00D10E72DA5" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:07:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFD01BAF11B61B00D10E72DA5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > On Nov 23, 2009, at 5:06 AM, Nelson B Bolyard wrote: >=20 >> On 2009-11-22 18:30 PST, Michael D'Errico wrote: >>> If you take an elitist position like the one you seem to be advocatin= g, >>> you run the risk that your "pure" standard-compliant fix will be igno= red >>> and people will come up with their own solutions. You will quickly >>> become irrelevant. >> >> The purveyors of all those old non-compliant products are desperately >> afraid that the browsers will unify and decide as a group to stop supp= orting >> fall-back for extension intolerant servers. Then those old >> servers would quickly become irrelevant. >=20 > Actually, patching servers is a lot easier than patching browsers. It's= fairly easy for a server administrator to replace the necessary library = (OpenSSL 0.9.8m?) with one that does TLS 1.3 and then we don't need any e= xtensions. >=20 > But these same servers need to support all the clients out there. That = includes the latest Firefox, but also the ever-prevalent IE6 on XP (with = and without patches and service packs), as well as an old iMac running Ma= c OS 8.6 with a Mozilla browser, and various phones. >=20 > So if the browsers unify, that's great. Maybe the browsers will standar= dize on TLS 1.3 and we can drop support for all older versions the moment= we decide that it's time to drop support for all pre-2010 browsers. I t= hink 2022 should do it. >=20 > In the meantime, we can't ignore that IE6 running on no-SP Windows XP. Your argument is self-defeating: if browsers are only upgraded slowly (by some subset of users), then that is an extremely good reason not to rely on browsers to be upgraded in order to prevent the attack. The only possible way to do that is for patched servers to reject renegotiations from unpatched browsers -- because such renegotiations cannot be distinguished from an instance of the attack. This will not break initial connections from unpatched browsers. It will require that servers avoid relying on renegotiation, but they can easily do so in a way that is compatible with IE6 or other unpatched browsers (for the most common use case of renegotiation -- prompting for a client cert for only some of the resources on a site -- it is sufficient to serv= e those resources on a different port). --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFD01BAF11B61B00D10E72DA5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksK62QACgkQWUc8YzyzqAcGNAEAiDPvn3xNm5OtJ0phS75YRKSh xM7GnNTghhaCaeGsvWMA/Ry90l4JqLRUAOco1UWdLnzGn1gx0xgGETc98KcGVhsq =7PLh -----END PGP SIGNATURE----- --------------enigFD01BAF11B61B00D10E72DA5-- From mrex@sap.com Mon Nov 23 12:07:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCF63A692B for ; Mon, 23 Nov 2009 12:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.117, 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 tnDizJhyyDGT for ; Mon, 23 Nov 2009 12:07:10 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 033723A68C3 for ; Mon, 23 Nov 2009 12:07:09 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nANK74Ll003878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 21:07:04 +0100 (MET) From: Martin Rex Message-Id: <200911232007.nANK736K022320@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Mon, 23 Nov 2009 21:07:03 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310BB2AB@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 23, 9 12:19:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:07:11 -0000 Pasi.Eronen@nokia.com wrote: > > Martin Rex wrote: > > > Does anyone remeber that the TLS WG gave the advice to people asking > > for identity protection to perform an initial client-anonymous TLS > > handshake directly followed by a renegotiation with client-cert > > authentication? > > > > (a related discussion what about gss-api authentication > > around 20-dec-2006, Subject: [TLS] Comments on TLS identity > > protection) > > Yes... and as Eric noted, as long as the 2nd handshake "directly > follows" (=no application data is exchanged using the first session), > this seems to be secure already.... But you do realize that there is an attack scenario where the server sees only an initial authentication, and the client sees a renegotiation? The MitM could use it to perform some kind of "bouncing-attack", where it feeds the client with a crafted request (like a form) and then links the client with the real server. So it is necessary for both sides to check, a check on the server alone is not sufficient. And if we're changing code, we could just as well deploy the fix for the weakness (provided TLS WG can agree on one solution). -Martin From nelson@bolyard.me Mon Nov 23 12:26:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907DB3A69F1 for ; Mon, 23 Nov 2009 12:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 uUCC2oYmnj+7 for ; Mon, 23 Nov 2009 12:26:54 -0800 (PST) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id D21333A69E6 for ; Mon, 23 Nov 2009 12:26:54 -0800 (PST) Received: (qmail 28597 invoked from network); 23 Nov 2009 20:26:46 -0000 Received: from unknown (24.5.142.42) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 23 Nov 2009 20:26:46 -0000 Message-ID: <4B0AF05F.9000408@bolyard.me> Date: Mon, 23 Nov 2009 12:28:15 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: IETF TLS Working Group References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> <4B09FC30.4070107@bolyard.me> <4B0A03C4.7030504@pobox.com> <4B0A0743.5000804@bolyard.me> <4B0AA334.4030901@pobox.com> In-Reply-To: <4B0AA334.4030901@pobox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:26:55 -0000 On 2009-11-23 06:59 PST, Michael D'Errico wrote: > I proposed a change to RI in another message that: > > - makes the extension empty in both directions on every handshake > - changes the Finished calc. in some way (there are various ways to > do it and I don't care which is chosen) > What I don't like about the current RI proposal is that it uses extensions > more than just as a signaling mechanism; you actually have to craft them > in both directions and extract the data at the other end. Plus as I pointed > out, you need to actually check that the data received is correct. Checking that data is correct is a very large part of the value of security software. > If you agree that this is better/simpler than the current RI proposal, I'd > appreciate it if you would send a note to the list enumerating these > benefits. I disagree with is emphatically. I disagree with changing the definition of the finished messages without changing the protocol version number. The IMPORTANT thing that RI accomplishes is that it gets the needed information included in the Finished message computations WITHOUT changing the definition of the Finished message computations. That is precisely its strength! That is precisely why I support it. From mrex@sap.com Mon Nov 23 12:43:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EEF3A68D5 for ; Mon, 23 Nov 2009 12:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.115, 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 gLomWlzUC0K6 for ; Mon, 23 Nov 2009 12:43:13 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D28D33A68B3 for ; Mon, 23 Nov 2009 12:43:12 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nANKh4qi014373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 21:43:04 +0100 (MET) From: Martin Rex Message-Id: <200911232043.nANKh4ah024321@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Mon, 23 Nov 2009 21:43:04 +0100 (MET) In-Reply-To: <4B0AF05F.9000408@bolyard.me> from "Nelson B Bolyard" at Nov 23, 9 12:28:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:43:13 -0000 Nelson B Bolyard wrote: > > I disagree with changing the definition of > the finished messages without changing the protocol version number. > The IMPORTANT thing that RI accomplishes is that it gets the needed > information included in the Finished message computations WITHOUT changing > the definition of the Finished message computations. That is precisely > its strength! That is precisely why I support it. Great! So you will not have a problem with my proposal either, because mine does not change the finished message computation either. http://www.ietf.org/mail-archive/web/tls/current/msg04194.html >From a cryptograpic standpoint, adding the verify_data into the handshake message hashes without sending them over the network is equivalent to adding them to the handshake messages itself, sending them over the wire and having to compare the values explicitly. Just that directly hashing them is less work and get a much better test coverage in regular interop testing, while TLS extension RI requires formal code review or penetration tests to achieve this. -Martin From stefan@aaa-sec.com Mon Nov 23 13:44:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75EFC3A67E6 for ; Mon, 23 Nov 2009 13:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onnUPWg9KAld for ; Mon, 23 Nov 2009 13:44:24 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id AD30C3A67AC for ; Mon, 23 Nov 2009 13:44:24 -0800 (PST) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DC4A5292D7B for ; Mon, 23 Nov 2009 22:44:26 +0100 (CET) Received: (qmail 43459 invoked from network); 23 Nov 2009 21:44:18 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Nov 2009 21:44:18 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 23 Nov 2009 22:44:17 +0100 From: Stefan Santesson To: Nelson B Bolyard , IETF TLS Working Group Message-ID: Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: AcpshhsgWBVjmNMJWkKQUWCoNlgIzQ== In-Reply-To: <4B0AF05F.9000408@bolyard.me> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:44:25 -0000 On 09-11-23 9:28 PM, "Nelson B Bolyard" wrote: >> If you agree that this is better/simpler than the current RI proposal, I'd >> appreciate it if you would send a note to the list enumerating these >> benefits. > > I disagree with is emphatically. I disagree with changing the definition of > the finished messages without changing the protocol version number. But changing the protocol version number is exactly what the alternative proposal is doing. > The IMPORTANT thing that RI accomplishes is that it gets the needed > information included in the Finished message computations WITHOUT changing > the definition of the Finished message computations. That is precisely > its strength! That is precisely why I support it. And this is also it's weakness as pointed out in previous mails, as it allows bad implementations of the fix to appear good. /Stefan From benl@google.com Mon Nov 23 14:12:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FA13A6AC3 for ; Mon, 23 Nov 2009 14:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 fvwUcDNjftXw for ; Mon, 23 Nov 2009 14:12:05 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 11A5D3A6A0C for ; Mon, 23 Nov 2009 14:12:04 -0800 (PST) Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id nANMBxm9001304 for ; Mon, 23 Nov 2009 22:11:59 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259014319; bh=zYSHetK3fILk2Z5Z5kR1bGExGAo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BNLFy1Ph9F3vRAba1cU8osWT1/Jo+fbTV18d860tF9KshktDSn98PgkVyYz6V27y5 fzWojzTLjHhLhBSWLKqbQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=QnWLw/QidIqlV5go+BfWwz5BXJ+vTZnozIOuVvxxA1xktevBOXsWcz1DtAz2aWen2 budASHMxPpRTAquawWwHA== Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by spaceape23.eur.corp.google.com with ESMTP id nANMBWL1022211 for ; Mon, 23 Nov 2009 14:11:57 -0800 Received: by qyk10 with SMTP id 10so3078303qyk.12 for ; Mon, 23 Nov 2009 14:11:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.50.149 with SMTP id z21mr725690qcf.86.1259014316665; Mon, 23 Nov 2009 14:11:56 -0800 (PST) In-Reply-To: <200911230306.nAN365xl020466@fs4113.wdf.sap.corp> References: <4B09ECAB.7050205@bolyard.me> <200911230306.nAN365xl020466@fs4113.wdf.sap.corp> Date: Mon, 23 Nov 2009 14:11:56 -0800 Message-ID: <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> From: Ben Laurie To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 22:12:26 -0000 On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: > It is the golden rule of the IETF > "be liberal in what you accept, be conservative in what you send out" That has proved to be a less-than-great idea, particularly in protocols where you care about security, which is to say, all of them. From Nicolas.Williams@sun.com Mon Nov 23 14:16:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1DD3A6844 for ; Mon, 23 Nov 2009 14:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.667 X-Spam-Level: X-Spam-Status: No, score=-5.667 tagged_above=-999 required=5 tests=[AWL=0.380, 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 FlYp40Rg6LJa for ; Mon, 23 Nov 2009 14:16:58 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 23CFD3A67E6 for ; Mon, 23 Nov 2009 14:16:56 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nANMGnC1000531 for ; Mon, 23 Nov 2009 22:16:49 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 nANMGnUX010498 for ; Mon, 23 Nov 2009 15:16:49 -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 nANLvdlY004192; Mon, 23 Nov 2009 15:57:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nANLvdIl004191; Mon, 23 Nov 2009 15:57:39 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 23 Nov 2009 15:57:39 -0600 From: Nicolas Williams To: Nelson B Bolyard Message-ID: <20091123215739.GN773@Sun.COM> References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> <4B09FC30.4070107@bolyard.me> <4B0A03C4.7030504@pobox.com> <4B0A0743.5000804@bolyard.me> <4B0AA334.4030901@pobox.com> <4B0AF05F.9000408@bolyard.me> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0AF05F.9000408@bolyard.me> User-Agent: Mutt/1.5.7i Cc: IETF TLS Working Group Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 22:16:59 -0000 On Mon, Nov 23, 2009 at 12:28:15PM -0800, Nelson B Bolyard wrote: > On 2009-11-23 06:59 PST, Michael D'Errico wrote: > > I proposed a change to RI in another message that: > > > > - makes the extension empty in both directions on every handshake > > - changes the Finished calc. in some way (there are various ways to > > do it and I don't care which is chosen) > > > What I don't like about the current RI proposal is that it uses extensions > > more than just as a signaling mechanism; you actually have to craft them > > in both directions and extract the data at the other end. Plus as I pointed > > out, you need to actually check that the data received is correct. > > Checking that data is correct is a very large part of the value of security > software. I prefer protocols where the checking is automatic. To be more specific in the context of this case: I prefer a solution where the two peers must have added the same channel binding inputs to some operation such that authentication will fail if they didn't. That said I support the RI proposal for the simple reason that it is ready to be deployed. Also: > > If you agree that this is better/simpler than the current RI proposal, I'd > > appreciate it if you would send a note to the list enumerating these > > benefits. > > I disagree with is emphatically. I disagree with changing the definition of > the finished messages without changing the protocol version number. I don't agree with you on this. The protocol version extensibility constraint that you are stating is completely arbitrary -- even if it were written into RFC5246 it'd still be as arbitrary and could not really bind the IETF in the future. Arbitrary extensibility constraints can be, and are useful, but if they lead to inferior solutions when new problems arise then they begin to lose their utility. > The IMPORTANT thing that RI accomplishes is that it gets the needed > information included in the Finished message computations WITHOUT changing > the definition of the Finished message computations. That is precisely > its strength! That is precisely why I support it. No, the important things about the RI proposal are that a) it does solve the problem, b) it's ready to be deployed. (b) alone would not be good enough, obviously, but, less obviously, neither would (a). Many alternative proposals have (a) and do it better, but only this one has (b). Perfect is the enemy of the good. IMO the RI proposal it is, even though I'd rather have a different solution, and even if some of us agree for different reasons. Nico -- From mrex@sap.com Mon Nov 23 14:20:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACF73A6876 for ; Mon, 23 Nov 2009 14:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 YA8uRG5afVNh for ; Mon, 23 Nov 2009 14:20:35 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6A7503A6812 for ; Mon, 23 Nov 2009 14:20:35 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nANMKT3G018082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 23:20:29 +0100 (MET) From: Martin Rex Message-Id: <200911232220.nANMKNKL000470@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 23 Nov 2009 23:20:23 +0100 (MET) In-Reply-To: <20091116054952.A520469F87E@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 07:49:51 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Deployment data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 22:20:37 -0000 Eric Rescorla wrote: > > > Clients bear the burden to make safe assumptions about what is going > > to be interoperable with the server, and safe protocol features > > are the reason why the amount of traffic on the internet that is > > still using prtocol version 0x03,0x00 (aka SSLv3) is _MUCH_ larger > > as the amount of public Web Servers that supports TLS. > > I'd be interested in seeing the data that supports the claim that > it is much larger. Can you provide references please? While archiving past discussions I noticed an incorrect statement I made. I'm sorry. What I wanted to say was: The amount of traffic on the internet that uses SSLv3 {0x03,0x00} is much larger than the amount of public Web-Servers that is SSLv3-only, because of clients that lack app-level reconnect fallbacks and therefore have to make safe/conservative assumptions about the protocol features supported by the server in order to get a reply instead of a TCP RST. -Martin From nelson@bolyard.me Mon Nov 23 14:56:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DE03A67E6 for ; Mon, 23 Nov 2009 14:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 CADOBqasfQ-m for ; Mon, 23 Nov 2009 14:56:16 -0800 (PST) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id AEA2F3A67CC for ; Mon, 23 Nov 2009 14:56:16 -0800 (PST) Received: (qmail 11860 invoked from network); 23 Nov 2009 22:56:11 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 23 Nov 2009 22:56:11 -0000 Message-ID: <4B0B137A.7050007@bolyard.me> Date: Mon, 23 Nov 2009 14:58:02 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <4B09ECAB.7050205@bolyard.me> <200911230306.nAN365xl020466@fs4113.wdf.sap.corp> <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> In-Reply-To: <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 22:56:17 -0000 On 2009-11-23 14:11 PST, Ben Laurie wrote: > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: >> It is the golden rule of the IETF >> "be liberal in what you accept, be conservative in what you send out" > > That has proved to be a less-than-great idea, particularly in > protocols where you care about security, which is to say, all of them. Precisely. From Nicolas.Williams@sun.com Mon Nov 23 15:36:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DA13A6AD7 for ; Mon, 23 Nov 2009 15:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[AWL=0.332, 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 hsnaJ2BJA0-v for ; Mon, 23 Nov 2009 15:36:01 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 89BF13A6AEB for ; Mon, 23 Nov 2009 15:36:01 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nANNZvUr019027 for ; Mon, 23 Nov 2009 23:35:57 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 nANNZv8h055073 for ; Mon, 23 Nov 2009 16:35:57 -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 nANNGmF4004300; Mon, 23 Nov 2009 17:16:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nANNGlq4004299; Mon, 23 Nov 2009 17:16:47 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 23 Nov 2009 17:16:47 -0600 From: Nicolas Williams To: Ben Laurie Message-ID: <20091123231646.GP773@Sun.COM> References: <4B09ECAB.7050205@bolyard.me> <200911230306.nAN365xl020466@fs4113.wdf.sap.corp> <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 23:36:02 -0000 On Mon, Nov 23, 2009 at 02:11:56PM -0800, Ben Laurie wrote: > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: > > It is the golden rule of the IETF > > "be liberal in what you accept, be conservative in what you send out" > > That has proved to be a less-than-great idea, particularly in > protocols where you care about security, which is to say, all of them. Sure, but consider this: a conservative design should fail safe. The RI proposal, as Michael D'Errico points out, allows for implementation failures that fail unsafe. Any alternative that has the two peers add the channel binding data for the outer/old connection to the Finished message verify_data computation without _sending_ the data as well will fail safe. IMO there are better solutions, but the RI proposal is ready for deployment at a moment's notice, and it is correct even if implementors can make this one annoying mistake and not notice. That is a huge plus for the RI proposal. Nico -- From mrex@sap.com Mon Nov 23 17:15:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6413A6ADA for ; Mon, 23 Nov 2009 17:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 qq5l56VQvYEw for ; Mon, 23 Nov 2009 17:14:59 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 48D8C3A693A for ; Mon, 23 Nov 2009 17:14:58 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAO1ErRK006090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Nov 2009 02:14:53 +0100 (MET) From: Martin Rex Message-Id: <200911240114.nAO1Erp2010951@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Tue, 24 Nov 2009 02:14:53 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:15:00 -0000 > > http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt One of the first feedback I received indicates that the amount of details in the document might make it appear much more complicated as it is. The idea of my proposal is to keep the changes to an absolute minimum (but offer secure renegotiation to all usage scenarios in the installed base). Solution brief: 1.) memorize verify_data from Client.Finished and Server.Finished in ConnectionState of current session 2.) on renegotiation handshakes, add memorized verify_data into handshake message hash to establish cryptographic binding 3.) C->S signaling with special cipher suite ID 4.) S->C signaling through highest bit in ServerHello.server_version additional explanation: 1.) is something that TLS extension RI needs as well 2.) is TLS extension RI on a diet and in failSAFE mode: - no fancy extension wrapping, - no re-send of the previous finished messages over the network - identical cryptographic properties, as described here: http://www.ietf.org/mail-archive/web/tls/current/msg04194.html TLS extension RI signals by presence of the extension, my proposal signals extension-less through existing protocol elements 3) is compatible with SSLv3 and SSLv2 ClientHello, 4) is compatible with SSLv3 ServerHello 3.) self-explaining, I hope 4.) I'm not changing the protocol version numbers anywhere in the protocol, just hitch-hiking an unused bit in ServerHello.server_version while traveling the network that hitch-hiking bit must be removed for all protocol-version related processing of server_version and not appear anywhere else, neither on the network and not in the code, beside the code that assembles the ServerHello PDU on the server and the code that parses the ServerHello PDU on the client. It will only be returned to clients sending (3). -Martin From nelson@bolyard.me Mon Nov 23 21:09:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6033A6B43 for ; Mon, 23 Nov 2009 21:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 PqQAxzGQEiqU for ; Mon, 23 Nov 2009 21:09:08 -0800 (PST) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id 2115A3A69FB for ; Mon, 23 Nov 2009 21:09:07 -0800 (PST) Received: (qmail 6730 invoked from network); 24 Nov 2009 05:09:02 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 24 Nov 2009 05:09:02 -0000 Message-ID: <4B0B6AE6.8040606@bolyard.me> Date: Mon, 23 Nov 2009 21:11:02 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911232043.nANKh4ah024321@fs4113.wdf.sap.corp> In-Reply-To: <200911232043.nANKh4ah024321@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:09:09 -0000 On 2009-11-23 12:43 PST, Martin Rex wrote: > Nelson B Bolyard wrote: >> I disagree with changing the definition of >> the finished messages without changing the protocol version number. >> The IMPORTANT thing that RI accomplishes is that it gets the needed >> information included in the Finished message computations WITHOUT changing >> the definition of the Finished message computations. That is precisely >> its strength! That is precisely why I support it. It does not change the finished message, or the computation of the handshake hashes. All remain 100% computable from the inputs to the present handshake. > Great! So you will not have a problem with my proposal either, > because mine does not change the finished message computation > either. > > http://www.ietf.org/mail-archive/web/tls/current/msg04194.html Your change makes the handshake hash (and hence the finished) no longer computable purely from the input to the current handshake. > From a cryptograpic standpoint, adding the verify_data into > the handshake message hashes without sending them over > the network is equivalent to adding them to the handshake > messages itself, sending them over the wire and having > to compare the values explicitly. > > Just that directly hashing them is less work It's a bigger code change, which is more to get wrong. Where have I heard that argument used before? From marsh@extendedsubset.com Mon Nov 23 23:56:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288C53A6810 for ; Mon, 23 Nov 2009 23:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 9oIWFesH4Osq for ; Mon, 23 Nov 2009 23:56:22 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 67F0C3A682A for ; Mon, 23 Nov 2009 23:56:22 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NCqG1-000NmD-Rc; Tue, 24 Nov 2009 07:56:17 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 36E236678; Tue, 24 Nov 2009 07:56:16 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18W0zfkuyw2dm1CDMvbNcKCogqLrTF+gEo= Message-ID: <4B0B919A.8060303@extendedsubset.com> Date: Tue, 24 Nov 2009 01:56:10 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B09ECAB.7050205@bolyard.me> <200911230306.nAN365xl020466@fs4113.wdf.sap.corp> <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> In-Reply-To: <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 07:56:23 -0000 Ben Laurie wrote: > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: >> It is the golden rule of the IETF >> "be liberal in what you accept, be conservative in what you send out" > > That has proved to be a less-than-great idea, particularly in > protocols where you care about security, which is to say, all of them. Another way to think about it: any time a receiver is being liberal in what it accepts the protocol is depending on undefined behavior. - Marsh From ynir@checkpoint.com Tue Nov 24 00:42:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9C13A68C5 for ; Tue, 24 Nov 2009 00:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 aAh0UkOSQyPd for ; Tue, 24 Nov 2009 00:42:24 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7AB8B3A6403 for ; Tue, 24 Nov 2009 00:42:24 -0800 (PST) X-CheckPoint: {4B0B98BD-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8ED7F29C018; Tue, 24 Nov 2009 10:42:15 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7224029C009; Tue, 24 Nov 2009 10:42:15 +0200 (IST) X-CheckPoint: {4B0B98B9-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAO8gEGo014462; Tue, 24 Nov 2009 10:42:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 10:42:20 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Tue, 24 Nov 2009 10:42:12 +0200 Thread-Topic: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted Thread-Index: Acps4gipewx9l+ZbSi2Ng9TQekIfdw== Message-ID: References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> In-Reply-To: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:42:25 -0000 Hi Martin. I see that you use the protocol field for the S->C signaling, but at least = it's on the ServerHello rather than the handshake record header. Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protoco= ls. A server answering with the wrong SSL version may just be "weird" enoug= h for the middlebox to drop the connection. I'm not at that side of Check P= oint, but I know that much of the protection code is not targeted at a part= icular attack, but just performs a sanity check on the protocols. On Nov 23, 2009, at 5:57 PM, Martin Rex wrote: > I have just submitted my proposal (I-D) to the IETF datatracker. >=20 > http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt >=20 >=20 > -Martin From ynir@checkpoint.com Tue Nov 24 01:08:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B12E3A686C for ; Tue, 24 Nov 2009 01:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 3V0YCxshxlBA for ; Tue, 24 Nov 2009 01:08:08 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AE0B13A6403 for ; Tue, 24 Nov 2009 01:08:07 -0800 (PST) X-CheckPoint: {4B0B9EC4-4-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A94EA29C018; Tue, 24 Nov 2009 11:08:02 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8602129C00E; Tue, 24 Nov 2009 11:08:02 +0200 (IST) X-CheckPoint: {4B0B9EC4-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAO981Go023142; Tue, 24 Nov 2009 11:08:02 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 11:08:07 +0200 From: Yoav Nir To: David-Sarah Hopwood Date: Tue, 24 Nov 2009 11:08:00 +0200 Thread-Topic: [TLS] Proposal for hybrid solution using most of the ideas Thread-Index: Acps5aM0d27ub89lTdqWtlJXZBEmqA== Message-ID: <0119D0CE-0E5A-4768-8E7E-6F271FE8B173@checkpoint.com> References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> <4B09FC30.4070107@bolyard.me> <64E272FB-7420-4B6A-B649-38487A539EF5@checkpoint.com> <4B0AEB53.1020702@jacaranda.org> In-Reply-To: <4B0AEB53.1020702@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 09:08:09 -0000 On Nov 23, 2009, at 10:06 PM, David-Sarah Hopwood wrote: > Yoav Nir wrote: >> On Nov 23, 2009, at 5:06 AM, Nelson B Bolyard wrote: >>=20 >>> On 2009-11-22 18:30 PST, Michael D'Errico wrote: >>>> If you take an elitist position like the one you seem to be advocating= , >>>> you run the risk that your "pure" standard-compliant fix will be ignor= ed >>>> and people will come up with their own solutions. You will quickly >>>> become irrelevant. >>>=20 >>> The purveyors of all those old non-compliant products are desperately >>> afraid that the browsers will unify and decide as a group to stop suppo= rting >>> fall-back for extension intolerant servers. Then those old >>> servers would quickly become irrelevant. >>=20 >> Actually, patching servers is a lot easier than patching browsers. It's = fairly easy for a server administrator to replace the necessary library (Op= enSSL 0.9.8m?) with one that does TLS 1.3 and then we don't need any extens= ions. >>=20 >> But these same servers need to support all the clients out there. That i= ncludes the latest Firefox, but also the ever-prevalent IE6 on XP (with and= without patches and service packs), as well as an old iMac running Mac OS = 8.6 with a Mozilla browser, and various phones. >>=20 >> So if the browsers unify, that's great. Maybe the browsers will standard= ize on TLS 1.3 and we can drop support for all older versions the moment we= decide that it's time to drop support for all pre-2010 browsers. I think = 2022 should do it. >>=20 >> In the meantime, we can't ignore that IE6 running on no-SP Windows XP. >=20 > Your argument is self-defeating: if browsers are only upgraded slowly > (by some subset of users), then that is an extremely good reason not to > rely on browsers to be upgraded in order to prevent the attack. The only > possible way to do that is for patched servers to reject renegotiations > from unpatched browsers -- because such renegotiations cannot be > distinguished from an instance of the attack. >=20 > This will not break initial connections from unpatched browsers. It will > require that servers avoid relying on renegotiation, but they can easily > do so in a way that is compatible with IE6 or other unpatched browsers > (for the most common use case of renegotiation -- prompting for a client > cert for only some of the resources on a site -- it is sufficient to serv= e > those resources on a different port). A different port is hard, but the usual way is to have a "login_with_mutual= _authentication.html" page, that is the only one where the renegotiation is= performed. That page plants a session cookie in the browser, if such a coo= kie does not yet exist, and performs no other action. You also need to reje= ct client-initiated renegotiation. If you do that, the only way for the attacker to force a renegotiation, is = to GET login_with_mutual_authentication.html, before the user logged in. Th= is will plant a cookie in the browser of the legitimate client, but that co= okie cannot be used for the attack, because the client's request has alread= y been created without the cookie. That's a way to support old browsers without being vulnerable. It only requ= ires a mild change to SSL (no client-initiated reneg) and a mild hardening = of the application. From simon@josefsson.org Tue Nov 24 03:21:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A11A3A69C3 for ; Tue, 24 Nov 2009 03:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 HUrIFhRhNu1n for ; Tue, 24 Nov 2009 03:21:57 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id BEEF83A69A6 for ; Tue, 24 Nov 2009 03:21:55 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAOBLiYJ031898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Nov 2009 12:21:46 +0100 From: Simon Josefsson To: Yoav Nir References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091124:mrex@sap.com::rQdQfwo0jELY6AVd:6V6h X-Hashcash: 1:22:091124:tls@ietf.org::n59+es1QdHabJ9ud:8bMZ X-Hashcash: 1:22:091124:ynir@checkpoint.com::cbW0Y/vDdVb4xToc:bYXV Date: Tue, 24 Nov 2009 12:21:44 +0100 In-Reply-To: (Yoav Nir's message of "Tue, 24 Nov 2009 10:42:12 +0200") Message-ID: <87aayci2wn.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tls@ietf.org" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 11:21:58 -0000 Yoav Nir writes: > Hi Martin. > > I see that you use the protocol field for the S->C signaling, but at least it's on the ServerHello rather than the handshake record header. > > Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protocols. A server answering with the wrong SSL version may just be "weird" enough for the middlebox to drop the connection. I'm not at that side of Check Point, but I know that much of the protection code is not targeted at a particular attack, but just performs a sanity check on the protocols. Presumably RI has the same concern: a deep-packet inspector may check for "unknown" extensions (similar to checking for "unknown" TLS versions) and reject the connection. I don't think this is a good argument to decide between the two proposals. IDSs will simply need to be upgraded to support one (or both) of the new proposals, and fortunately that is already required for other reasons, so it seems like a small concern to me. /Simon > On Nov 23, 2009, at 5:57 PM, Martin Rex wrote: > >> I have just submitted my proposal (I-D) to the IETF datatracker. >> >> http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt >> >> >> -Martin From ynir@checkpoint.com Tue Nov 24 04:02:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4043A6856 for ; Tue, 24 Nov 2009 04:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 KAudMbrrkxMt for ; Tue, 24 Nov 2009 04:02:27 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 52E763A67B8 for ; Tue, 24 Nov 2009 04:02:25 -0800 (PST) X-CheckPoint: {4B0BC799-8-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id ED96329C01B; Tue, 24 Nov 2009 14:02:16 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C77CA29C019; Tue, 24 Nov 2009 14:02:16 +0200 (IST) X-CheckPoint: {4B0BC799-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAOC2GGo010563; Tue, 24 Nov 2009 14:02:16 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 14:02:21 +0200 From: Yoav Nir To: Simon Josefsson Date: Tue, 24 Nov 2009 14:02:14 +0200 Thread-Topic: draft-mrex-tls-secure-renegotiation-00.txt submitted Thread-Index: Acps/fogKrINa1fMSVKLmKnB46vkSw== Message-ID: <23ACBC75-62CC-4521-8BB5-A3D425C07204@checkpoint.com> References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> <87aayci2wn.fsf@mocca.josefsson.org> In-Reply-To: <87aayci2wn.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:02:28 -0000 On Nov 24, 2009, at 1:21 PM, Simon Josefsson wrote: > Yoav Nir writes: >=20 >> Hi Martin. >>=20 >> I see that you use the protocol field for the S->C signaling, but at lea= st it's on the ServerHello rather than the handshake record header. >>=20 >> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect prot= ocols. A server answering with the wrong SSL version may just be "weird" en= ough for the middlebox to drop the connection. I'm not at that side of Chec= k Point, but I know that much of the protection code is not targeted at a p= articular attack, but just performs a sanity check on the protocols. >=20 > Presumably RI has the same concern: a deep-packet inspector may check > for "unknown" extensions (similar to checking for "unknown" TLS > versions) and reject the connection. >=20 > I don't think this is a good argument to decide between the two > proposals. IDSs will simply need to be upgraded to support one (or > both) of the new proposals, and fortunately that is already required for > other reasons, so it seems like a small concern to me. I've said several times that I prefer Martin's approach. It's just that I'd= prefer a more subtle way for the S->C signalling (like something in the ra= ndom or GMT) An unknown ciphersuite is weird, but in a world with GOST and Camelia, you = can't drop TLS handshakes based on that. A magic timestamp is weird, but we already have implementations randomizing= this field, so IDSs are already "trained" to ignore this. Unknown extensions are a new kind of weirdness, but since they're allowed b= y the protocol, I don't expect much trouble there either. Replying with version 131.1 to a request from version 3.1 is a clear protoc= ol violation that may get noticed. Again, I'd be much more worried if this = was in the record header, but I'm a little bit worried like this.= From simon@josefsson.org Tue Nov 24 04:27:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9910D3A6A32 for ; Tue, 24 Nov 2009 04:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 gkmYd--9FrKh for ; Tue, 24 Nov 2009 04:27:23 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 52EB63A6931 for ; Tue, 24 Nov 2009 04:27:23 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAOCR87k000491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Nov 2009 13:27:12 +0100 From: Simon Josefsson To: Yoav Nir References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> <87aayci2wn.fsf@mocca.josefsson.org> <23ACBC75-62CC-4521-8BB5-A3D425C07204@checkpoint.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091124:ynir@checkpoint.com::ZjKYbnVeVMvehC1c:Am8K X-Hashcash: 1:22:091124:tls@ietf.org::90l2wTnHYZlhCvsW:IuVe Date: Tue, 24 Nov 2009 13:27:05 +0100 In-Reply-To: <23ACBC75-62CC-4521-8BB5-A3D425C07204@checkpoint.com> (Yoav Nir's message of "Tue, 24 Nov 2009 14:02:14 +0200") Message-ID: <876390glba.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tls@ietf.org" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:27:24 -0000 Yoav Nir writes: > On Nov 24, 2009, at 1:21 PM, Simon Josefsson wrote: > >> Yoav Nir writes: >> >>> Hi Martin. >>> >>> I see that you use the protocol field for the S->C signaling, but at least it's on the ServerHello rather than the handshake record header. >>> >>> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protocols. A server answering with the wrong SSL version may just be "weird" enough for the middlebox to drop the connection. I'm not at that side of Check Point, but I know that much of the protection code is not targeted at a particular attack, but just performs a sanity check on the protocols. >> >> Presumably RI has the same concern: a deep-packet inspector may check >> for "unknown" extensions (similar to checking for "unknown" TLS >> versions) and reject the connection. >> >> I don't think this is a good argument to decide between the two >> proposals. IDSs will simply need to be upgraded to support one (or >> both) of the new proposals, and fortunately that is already required for >> other reasons, so it seems like a small concern to me. > > I've said several times that I prefer Martin's approach. It's just > that I'd prefer a more subtle way for the S->C signalling (like > something in the random or GMT) Here is another idea: use one bit of the ciphersuite space. So if the server would have selected TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 } if the server would support the renegotiation protocol it would return { 0x70, 0x13 } or { 0x00, 0x13 | 0x70 } or similar instead. It is an ugly solution, but I haven't seen it mentioned. /Simon From Christoph.Sprongl@it-austria.com Tue Nov 24 04:31:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6A828C0E5 for ; Tue, 24 Nov 2009 04:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mHA5FkqDXJN for ; Tue, 24 Nov 2009 04:31:50 -0800 (PST) Received: from zep4.it-austria.net (zep4.it-austria.net [213.150.3.135]) by core3.amsl.com (Postfix) with ESMTP id A74933A68B8 for ; Tue, 24 Nov 2009 04:31:47 -0800 (PST) Received: from a2xmxmr1.A2X.LAN.AT (exchange2k7.it-austria.com [162.25.81.84]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by zep4.it-austria.net (Postfix) with ESMTPS id D1EA6D09AF for ; Tue, 24 Nov 2009 13:31:41 +0100 (CET) Received: from a2xmxs1v1.A2X.LAN.AT ([fe80:0000:0000:0000:2c6c:4252:176.33.185.93]) by a2xmxmr1.A2X.LAN.AT ([162.25.81.84]) with mapi; Tue, 24 Nov 2009 13:31:41 +0100 From: SPRONGL Christoph To: "tls@ietf.org" Date: Tue, 24 Nov 2009 13:31:40 +0100 Thread-Topic: TLS Digest Thread-Index: Acps+GaTTalfQUsmQA6pKm4xullMEgACYAvw Message-ID: <1C63FFB4E7581F4E9CB6476A096367F7884D001EFA@A2XMXS1V1.A2X.LAN.AT> References: In-Reply-To: Accept-Language: en-US, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Atry Auo/ CNMD CpA7 HSuT IEeK IUv2 JCBD JIZu JddW JqQ9 JtTL J+CB K1mT K8Cz LB6v; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {1999F83E-F817-42B2-BD5D-DD124005DD40}; YwBoAHIAaQBzAHQAbwBwAGgALgBzAHAAcgBvAG4AZwBsAEAAaQB0AC0AYQB1AHMAdAByAGkAYQAuAGMAbwBtAA==; Tue, 24 Nov 2009 12:31:40 GMT;QQBXADoAIABUAEwAUwAgAEQAaQBnAGUAcwB0AA== x-cr-puzzleid: {1999F83E-F817-42B2-BD5D-DD124005DD40} acceptlanguage: en-US, de-AT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS Digest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:31:52 -0000 How is the roadmap of the proposal? - When will the time for the updates co= me? ch -----Urspr=FCngliche Nachricht----- Von: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] Im Auftrag von tls-= request@ietf.org Gesendet: Dienstag, 24. November 2009 12:22 An: tls@ietf.org Betreff: TLS Digest, Vol 64, Issue 130 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/tls Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send TLS mailing list submissions to tls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/tls or, via email, send a message with subject or body 'help' to tls-request@ietf.org You can reach the person managing the list at tls-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TLS digest..." Today's Topics: 1. Re: Proposal for hybrid solution using most of the ideas (Nelson B Bolyard) 2. Re: Proposal for hybrid solution using most of the ideas (Nicolas Williams) 3. Re: draft-mrex-tls-secure-renegotiation-00.txt (Martin Rex) 4. Re: Proposal for hybrid solution using most of the ideas (Nelson B Bolyard) 5. Re: Proposal for hybrid solution using most of the ideas (Marsh Ray) 6. Re: draft-mrex-tls-secure-renegotiation-00.txt submitted (Yoav Nir) 7. Re: Proposal for hybrid solution using most of the ideas (Yoav Nir) 8. Re: draft-mrex-tls-secure-renegotiation-00.txt submitted (Simon Josefsson) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Nov 2009 14:58:02 -0800 From: Nelson B Bolyard Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas To: tls@ietf.org Message-ID: <4B0B137A.7050007@bolyard.me> Content-Type: text/plain; charset=3DUTF-8 On 2009-11-23 14:11 PST, Ben Laurie wrote: > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: >> It is the golden rule of the IETF >> "be liberal in what you accept, be conservative in what you send out" > > That has proved to be a less-than-great idea, particularly in > protocols where you care about security, which is to say, all of them. Precisely. ------------------------------ Message: 2 Date: Mon, 23 Nov 2009 17:16:47 -0600 From: Nicolas Williams Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas To: Ben Laurie Cc: tls@ietf.org Message-ID: <20091123231646.GP773@Sun.COM> Content-Type: text/plain; charset=3Dus-ascii On Mon, Nov 23, 2009 at 02:11:56PM -0800, Ben Laurie wrote: > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: > > It is the golden rule of the IETF > > "be liberal in what you accept, be conservative in what you send out" > > That has proved to be a less-than-great idea, particularly in > protocols where you care about security, which is to say, all of them. Sure, but consider this: a conservative design should fail safe. The RI proposal, as Michael D'Errico points out, allows for implementation failures that fail unsafe. Any alternative that has the two peers add the channel binding data for the outer/old connection to the Finished message verify_data computation without _sending_ the data as well will fail safe. IMO there are better solutions, but the RI proposal is ready for deployment at a moment's notice, and it is correct even if implementors can make this one annoying mistake and not notice. That is a huge plus for the RI proposal. Nico -- ------------------------------ Message: 3 Date: Tue, 24 Nov 2009 02:14:53 +0100 (MET) From: Martin Rex Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt To: tls@ietf.org Message-ID: <200911240114.nAO1Erp2010951@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=3DISO-8859-1 > > http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt One of the first feedback I received indicates that the amount of details in the document might make it appear much more complicated as it is= . The idea of my proposal is to keep the changes to an absolute minimum (but offer secure renegotiation to all usage scenarios in the installed base). Solution brief: 1.) memorize verify_data from Client.Finished and Server.Finished in ConnectionState of current session 2.) on renegotiation handshakes, add memorized verify_data into handshake message hash to establish cryptographic binding 3.) C->S signaling with special cipher suite ID 4.) S->C signaling through highest bit in ServerHello.server_version additional explanation: 1.) is something that TLS extension RI needs as well 2.) is TLS extension RI on a diet and in failSAFE mode: - no fancy extension wrapping, - no re-send of the previous finished messages over the network - identical cryptographic properties, as described here: http://www.ietf.org/mail-archive/web/tls/current/msg04194.html TLS extension RI signals by presence of the extension, my proposal signals extension-less through existing protocol elements 3) is compatible with SSLv3 and SSLv2 ClientHello, 4) is compatible with SSLv3 ServerHello 3.) self-explaining, I hope 4.) I'm not changing the protocol version numbers anywhere in the protocol, just hitch-hiking an unused bit in ServerHello.server_version while traveling the network that hitch-hiking bit must be removed for all protocol-version related processing of server_version and not appear anywhere else, neither on the network and not in the code, beside the code that assembles the ServerHello PDU on the server and the code that parses the ServerHello PDU on the client. It will only be returned to clients sending (3). -Martin ------------------------------ Message: 4 Date: Mon, 23 Nov 2009 21:11:02 -0800 From: Nelson B Bolyard Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas To: tls@ietf.org Message-ID: <4B0B6AE6.8040606@bolyard.me> Content-Type: text/plain; charset=3DUTF-8 On 2009-11-23 12:43 PST, Martin Rex wrote: > Nelson B Bolyard wrote: >> I disagree with changing the definition of >> the finished messages without changing the protocol version number. >> The IMPORTANT thing that RI accomplishes is that it gets the needed >> information included in the Finished message computations WITHOUT changi= ng >> the definition of the Finished message computations. That is precisely >> its strength! That is precisely why I support it. It does not change the finished message, or the computation of the handshak= e hashes. All remain 100% computable from the inputs to the present handshake. > Great! So you will not have a problem with my proposal either, > because mine does not change the finished message computation > either. > > http://www.ietf.org/mail-archive/web/tls/current/msg04194.html Your change makes the handshake hash (and hence the finished) no longer computable purely from the input to the current handshake. > From a cryptograpic standpoint, adding the verify_data into > the handshake message hashes without sending them over > the network is equivalent to adding them to the handshake > messages itself, sending them over the wire and having > to compare the values explicitly. > > Just that directly hashing them is less work It's a bigger code change, which is more to get wrong. Where have I heard that argument used before? ------------------------------ Message: 5 Date: Tue, 24 Nov 2009 01:56:10 -0600 From: Marsh Ray Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas To: tls@ietf.org Message-ID: <4B0B919A.8060303@extendedsubset.com> Content-Type: text/plain; charset=3DISO-8859-1 Ben Laurie wrote: > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: >> It is the golden rule of the IETF >> "be liberal in what you accept, be conservative in what you send out" > > That has proved to be a less-than-great idea, particularly in > protocols where you care about security, which is to say, all of them. Another way to think about it: any time a receiver is being liberal in what it accepts the protocol is depending on undefined behavior. - Marsh ------------------------------ Message: 6 Date: Tue, 24 Nov 2009 10:42:12 +0200 From: Yoav Nir Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted To: "mrex@sap.com" Cc: "tls@ietf.org" Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Martin. I see that you use the protocol field for the S->C signaling, but at least = it's on the ServerHello rather than the handshake record header. Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protoco= ls. A server answering with the wrong SSL version may just be "weird" enoug= h for the middlebox to drop the connection. I'm not at that side of Check P= oint, but I know that much of the protection code is not targeted at a part= icular attack, but just performs a sanity check on the protocols. On Nov 23, 2009, at 5:57 PM, Martin Rex wrote: > I have just submitted my proposal (I-D) to the IETF datatracker. > > http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt > > > -Martin ------------------------------ Message: 7 Date: Tue, 24 Nov 2009 11:08:00 +0200 From: Yoav Nir Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas To: David-Sarah Hopwood Cc: "tls@ietf.org" Message-ID: <0119D0CE-0E5A-4768-8E7E-6F271FE8B173@checkpoint.com> Content-Type: text/plain; charset=3D"us-ascii" On Nov 23, 2009, at 10:06 PM, David-Sarah Hopwood wrote: > Yoav Nir wrote: >> On Nov 23, 2009, at 5:06 AM, Nelson B Bolyard wrote: >> >>> On 2009-11-22 18:30 PST, Michael D'Errico wrote: >>>> If you take an elitist position like the one you seem to be advocating= , >>>> you run the risk that your "pure" standard-compliant fix will be ignor= ed >>>> and people will come up with their own solutions. You will quickly >>>> become irrelevant. >>> >>> The purveyors of all those old non-compliant products are desperately >>> afraid that the browsers will unify and decide as a group to stop suppo= rting >>> fall-back for extension intolerant servers. Then those old >>> servers would quickly become irrelevant. >> >> Actually, patching servers is a lot easier than patching browsers. It's = fairly easy for a server administrator to replace the necessary library (Op= enSSL 0.9.8m?) with one that does TLS 1.3 and then we don't need any extens= ions. >> >> But these same servers need to support all the clients out there. That i= ncludes the latest Firefox, but also the ever-prevalent IE6 on XP (with and= without patches and service packs), as well as an old iMac running Mac OS = 8.6 with a Mozilla browser, and various phones. >> >> So if the browsers unify, that's great. Maybe the browsers will standard= ize on TLS 1.3 and we can drop support for all older versions the moment we= decide that it's time to drop support for all pre-2010 browsers. I think = 2022 should do it. >> >> In the meantime, we can't ignore that IE6 running on no-SP Windows XP. > > Your argument is self-defeating: if browsers are only upgraded slowly > (by some subset of users), then that is an extremely good reason not to > rely on browsers to be upgraded in order to prevent the attack. The only > possible way to do that is for patched servers to reject renegotiations > from unpatched browsers -- because such renegotiations cannot be > distinguished from an instance of the attack. > > This will not break initial connections from unpatched browsers. It will > require that servers avoid relying on renegotiation, but they can easily > do so in a way that is compatible with IE6 or other unpatched browsers > (for the most common use case of renegotiation -- prompting for a client > cert for only some of the resources on a site -- it is sufficient to serv= e > those resources on a different port). A different port is hard, but the usual way is to have a "login_with_mutual= _authentication.html" page, that is the only one where the renegotiation is= performed. That page plants a session cookie in the browser, if such a coo= kie does not yet exist, and performs no other action. You also need to reje= ct client-initiated renegotiation. If you do that, the only way for the attacker to force a renegotiation, is = to GET login_with_mutual_authentication.html, before the user logged in. Th= is will plant a cookie in the browser of the legitimate client, but that co= okie cannot be used for the attack, because the client's request has alread= y been created without the cookie. That's a way to support old browsers without being vulnerable. It only requ= ires a mild change to SSL (no client-initiated reneg) and a mild hardening = of the application. ------------------------------ Message: 8 Date: Tue, 24 Nov 2009 12:21:44 +0100 From: Simon Josefsson Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted To: Yoav Nir Cc: "tls@ietf.org" Message-ID: <87aayci2wn.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=3Dus-ascii Yoav Nir writes: > Hi Martin. > > I see that you use the protocol field for the S->C signaling, but at leas= t it's on the ServerHello rather than the handshake record header. > > Still, I'm worried about firewall/IPS/IDS devices that deep-inspect proto= cols. A server answering with the wrong SSL version may just be "weird" eno= ugh for the middlebox to drop the connection. I'm not at that side of Check= Point, but I know that much of the protection code is not targeted at a pa= rticular attack, but just performs a sanity check on the protocols. Presumably RI has the same concern: a deep-packet inspector may check for "unknown" extensions (similar to checking for "unknown" TLS versions) and reject the connection. I don't think this is a good argument to decide between the two proposals. IDSs will simply need to be upgraded to support one (or both) of the new proposals, and fortunately that is already required for other reasons, so it seems like a small concern to me. /Simon > On Nov 23, 2009, at 5:57 PM, Martin Rex wrote: > >> I have just submitted my proposal (I-D) to the IETF datatracker. >> >> http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt >> >> >> -Martin ------------------------------ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls End of TLS Digest, Vol 64, Issue 130 ************************************ From ynir@checkpoint.com Tue Nov 24 05:50:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5225C3A69ED for ; Tue, 24 Nov 2009 05:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 tgGtNYGSsA-y for ; Tue, 24 Nov 2009 05:50:26 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 234BC3A6784 for ; Tue, 24 Nov 2009 05:50:26 -0800 (PST) X-CheckPoint: {4B0BE0ED-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 835B029C017; Tue, 24 Nov 2009 15:50:17 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6DA4C29C004; Tue, 24 Nov 2009 15:50:17 +0200 (IST) X-CheckPoint: {4B0BE0E9-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAODoGGo009460; Tue, 24 Nov 2009 15:50:17 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 15:50:22 +0200 From: Yoav Nir To: Simon Josefsson Date: Tue, 24 Nov 2009 15:50:15 +0200 Thread-Topic: draft-mrex-tls-secure-renegotiation-00.txt submitted Thread-Index: AcptDREnBC4C1jzAS0eBlMwcic1X+Q== Message-ID: References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> <87aayci2wn.fsf@mocca.josefsson.org> <23ACBC75-62CC-4521-8BB5-A3D425C07204@checkpoint.com> <876390glba.fsf@mocca.josefsson.org> In-Reply-To: <876390glba.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 13:50:27 -0000 On Nov 24, 2009, at 2:27 PM, Simon Josefsson wrote: > Yoav Nir writes: >=20 >> On Nov 24, 2009, at 1:21 PM, Simon Josefsson wrote: >>=20 >>> Yoav Nir writes: >>>=20 >>>> Hi Martin. >>>>=20 >>>> I see that you use the protocol field for the S->C signaling, but at l= east it's on the ServerHello rather than the handshake record header. >>>>=20 >>>> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect pr= otocols. A server answering with the wrong SSL version may just be "weird" = enough for the middlebox to drop the connection. I'm not at that side of Ch= eck Point, but I know that much of the protection code is not targeted at a= particular attack, but just performs a sanity check on the protocols. >>>=20 >>> Presumably RI has the same concern: a deep-packet inspector may check >>> for "unknown" extensions (similar to checking for "unknown" TLS >>> versions) and reject the connection. >>>=20 >>> I don't think this is a good argument to decide between the two >>> proposals. IDSs will simply need to be upgraded to support one (or >>> both) of the new proposals, and fortunately that is already required fo= r >>> other reasons, so it seems like a small concern to me. >>=20 >> I've said several times that I prefer Martin's approach. It's just >> that I'd prefer a more subtle way for the S->C signalling (like >> something in the random or GMT) >=20 > Here is another idea: use one bit of the ciphersuite space. So if the > server would have selected TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA =3D { > 0x00,0x13 } if the server would support the renegotiation protocol it > would return { 0x70, 0x13 } or { 0x00, 0x13 | 0x70 } or similar instead. >=20 > It is an ugly solution, but I haven't seen it mentioned. Actually, it's not that ugly, as a new ciphersuite can dictate some changes= to the Finished message. This also takes care of both C->S and S->C signal= ling. OTOH, it doubles the amount of defined ciphersuites= From lists@drh-consultancy.demon.co.uk Tue Nov 24 06:09:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68E13A681B for ; Tue, 24 Nov 2009 06:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 hSDyhIGtM-nW for ; Tue, 24 Nov 2009 06:09:11 -0800 (PST) Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by core3.amsl.com (Postfix) with ESMTP id 917693A6784 for ; Tue, 24 Nov 2009 06:09:11 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49905 helo=[192.168.7.8]) by relay00.mail.eu.clara.net (relay.clara.net [213.253.3.40]:10587) with esmtpa (authdaemon_plain:drh) id 1NCw4n-0007tS-0n (Exim 4.69) for tls@ietf.org (return-path ); Tue, 24 Nov 2009 14:09:06 +0000 Message-ID: <4B0BE902.6070803@drh-consultancy.demon.co.uk> Date: Tue, 24 Nov 2009 14:09:06 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> <87aayci2wn.fsf@mocca.josefsson.org> <23ACBC75-62CC-4521-8BB5-A3D425C07204@checkpoint.com> <876390glba.fsf@mocca.josefsson.org> In-Reply-To: <876390glba.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:09:12 -0000 Simon Josefsson wrote: > Yoav Nir writes: > >> On Nov 24, 2009, at 1:21 PM, Simon Josefsson wrote: >> >>> Yoav Nir writes: >>> >>>> Hi Martin. >>>> >>>> I see that you use the protocol field for the S->C signaling, but at least it's on the ServerHello rather than the handshake record header. >>>> >>>> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protocols. A server answering with the wrong SSL version may just be "weird" enough for the middlebox to drop the connection. I'm not at that side of Check Point, but I know that much of the protection code is not targeted at a particular attack, but just performs a sanity check on the protocols. >>> Presumably RI has the same concern: a deep-packet inspector may check >>> for "unknown" extensions (similar to checking for "unknown" TLS >>> versions) and reject the connection. >>> >>> I don't think this is a good argument to decide between the two >>> proposals. IDSs will simply need to be upgraded to support one (or >>> both) of the new proposals, and fortunately that is already required for >>> other reasons, so it seems like a small concern to me. >> I've said several times that I prefer Martin's approach. It's just >> that I'd prefer a more subtle way for the S->C signalling (like >> something in the random or GMT) > > Here is another idea: use one bit of the ciphersuite space. So if the > server would have selected TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { > 0x00,0x13 } if the server would support the renegotiation protocol it > would return { 0x70, 0x13 } or { 0x00, 0x13 | 0x70 } or similar instead. > > It is an ugly solution, but I haven't seen it mentioned. > Could use one bit of the compression_method field in ServerHello. Since there are only two actually defined since it first appeared in SSLv3 I don't think we'll run out any time soon. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Tue Nov 24 06:17:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAB128C111 for ; Tue, 24 Nov 2009 06:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.111, 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 15AIoRhLx60I for ; Tue, 24 Nov 2009 06:17:49 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A56213A693C for ; Tue, 24 Nov 2009 06:17:48 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAOEHZM6020759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 15:17:35 +0100 (MET) From: Martin Rex Message-Id: <200911241417.nAOEHScP000631@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Tue, 24 Nov 2009 15:17:25 +0100 (MET) In-Reply-To: <876390glba.fsf@mocca.josefsson.org> from "Simon Josefsson" at Nov 24, 9 01:27:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:17:49 -0000 Simon Josefsson wrote: > > Here is another idea: use one bit of the ciphersuite space. So if the > server would have selected TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { > 0x00,0x13 } if the server would support the renegotiation protocol it > would return { 0x70, 0x13 } or { 0x00, 0x13 | 0x70 } or similar instead. > > It is an ugly solution, but I haven't seen it mentioned. I briefly thought about it, but didn't like it myself. The cipher suite value is partitioned into ranges, and part of that is for private use, so we may have accidental collisions. There is much less contention on the server_version.major, that hasn't seen a lot of change for a while. :) -Martin From mrex@sap.com Tue Nov 24 06:29:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9EB3A6A5D for ; Tue, 24 Nov 2009 06:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 WpaI5ZNrddWO for ; Tue, 24 Nov 2009 06:29:11 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id AD6DC3A69A2 for ; Tue, 24 Nov 2009 06:29:10 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAOET34o003904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 15:29:03 +0100 (MET) From: Martin Rex Message-Id: <200911241428.nAOESv9W001476@fs4113.wdf.sap.corp> To: lists@drh-consultancy.demon.co.uk (Dr Stephen Henson) Date: Tue, 24 Nov 2009 15:28:51 +0100 (MET) In-Reply-To: <4B0BE902.6070803@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Nov 24, 9 02:09:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:29:11 -0000 Dr Stephen Henson wrote: > > Could use one bit of the compression_method field in ServerHello. Since there > are only two actually defined since it first appeared in SSLv3 I don't think > we'll run out any time soon. You mean for S->C signaling in ServerHello? Should be doable. The confusion about unknown compression algs is only in the ClientHello. On the way back, we can specify what we want to do. The normal math on the cipher_suites and the compression_algs is that the server is going to return a value from the _explicit_ set proposed by the client. With the server_version there is acutally no set, only the highest value desired by the client is sent in ClientHello.server_version and the server is supposed to select an interoperable protocol version (that should not be newer than the version proposed by the client). If the server sends back 0x83,0x01 instead of 0x03,0x01 then it is still talking TLSv1.0 (0x03,0x01), but will authenticate the previously exchanged Finished messages as if they were part of the current handshake in order to create a cryptographic binding from the enclosing TLS session to the renegotiation handshake. That is somewhat of an orthogonal protocol change in order to fix a security vulnerability in the original renegotiation. Personally, I prefer to use the server_version.major, but it is certainly not that my life would depend on this choice. I'm still open to suggestions. -Martin From stefan@aaa-sec.com Tue Nov 24 06:44:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722983A6A62 for ; Tue, 24 Nov 2009 06:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwOI6Mn+OPbP for ; Tue, 24 Nov 2009 06:44:16 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 352273A6A49 for ; Tue, 24 Nov 2009 06:44:15 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 11173289EF6 for ; Tue, 24 Nov 2009 15:44:15 +0100 (CET) Received: (qmail 25980 invoked from network); 24 Nov 2009 14:44:09 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Nov 2009 14:44:09 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 15:44:08 +0100 From: Stefan Santesson To: IETF TLS Working Group Message-ID: Thread-Topic: Other S->C signaling methods Thread-Index: AcptFJPNroqeote4U0ifL2DMrDOQjg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341922249_32883127" Subject: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:44:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3341922249_32883127 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I have some more crazy ideas to throw into the bucket for the S->C signaling. We have been pretty locked on trying to squeeze the 1 bit of information form the server (I support secure renegotiation) in any of the existing fields of the handshake, or the server hello. The main reason we don=B9t want to use extensions is valid for C->S, since we don=B9t want to break servers that can=B9t handle extensions. But the same rationale is not necessarily true for S->C signaling since: 1. The client has already declared that it is patched (through magic ciphe suite), and should be able to accept whatever the server sends back as proof.=20 2. The server should be able to add whatever data to its handshake message structure once it has accepted that the client is patched. So for S->C, as an alternative to abuse current fields, I see a number of other potentially valid alternatives: 1. Return an RI extension, even if one was not sent by the client. The problem is that this is a violation of the TLS protocol. It is illegal to add a server extension that was not present in the client hello. But except that problem, it might work. 2. Extend the Server Hello with a new secure renegotiation confirmation value/flag.=20 3. Define a new handshake message that is sent right after ServerHello. Thi= s handshake message would be sent back to the client only of the magic CipherSuite was sent by the client, confirming that the server supports updated finished messages. I=B9m not sure whether this would cause any seriou= s problems, but in case it doesn=B9t, this is the one I like best. /Stefan --B_3341922249_32883127 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Other S->C signaling methods I have some more crazy ideas to throw into the bucket for the S->C sign= aling.

We have been pretty locked on trying to squeeze the 1 bit of information fo= rm the server (I support secure renegotiation) in any of the existing fields= of the handshake, or the server hello.

The main reason we don’t want to use extensions is valid for C->S,= since we don’t want to break servers that can’t handle extensio= ns.
But the same rationale is not necessarily true for S->C signaling since:=

  1. The client has already declared that it is patched (= through magic ciphe suite), and should be able to accept whatever the server= sends back as proof.
  2. The server should be able to add whatever data to its ha= ndshake message structure once it has accepted that the client is patched.


So for S->C, as an alternative to abuse current fields, I see a number o= f other potentially valid alternatives:

  1. Return an RI extension, even if one was not sent by = the client. The problem is that this is a violation of the TLS protocol. It = is illegal to add a server extension that was not present in the client hell= o. But except that problem, it might work.
  2. Extend the Server Hello with a new secure renegotiation = confirmation value/flag.
  3. Define a new handshake message that is sent right after = ServerHello. This handshake message would be sent back to the client only of= the magic CipherSuite was sent by the client, confirming that the server su= pports updated finished messages. I’m not sure whether this would caus= e any serious problems, but in case it doesn’t, this is the one I like= best.

/Stefan --B_3341922249_32883127-- From mrex@sap.com Tue Nov 24 07:33:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE783A6AA0 for ; Tue, 24 Nov 2009 07:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.108, 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 xvey0SY4GXPq for ; Tue, 24 Nov 2009 07:33:00 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 8E9603A6A56 for ; Tue, 24 Nov 2009 07:32:59 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAOFWrhS029027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 16:32:53 +0100 (MET) From: Martin Rex Message-Id: <200911241532.nAOFWoQh005340@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Tue, 24 Nov 2009 16:32:42 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Nov 24, 9 03:44:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:33:01 -0000 Stefan Santesson wrote: > > 1. The client has already declared that it is patched (through magic ciphe > suite), and should be able to accept whatever the server sends back as > proof. > > 2. The server should be able to add whatever data to its handshake message > structure once it has accepted that the client is patched. Theoretically you are correct. We're doing a negotiation and in the S->C reply, that is only sent when the client indicated that it will understand the answer, we could define a whole new protocol. But in practice, we want the fix to change as little as possible and work in all existing usage scenarios. That certainly includes those scenarios that are actively using TLS extensions. IMHO, that means we should make it fit into SSLv3 ServerHello (which is a part of ExtendedServerHello) Allowing servers to return a fixed octet string that represents a correctly encoded single extension in the ServerHello might be an option -- but this is something that we can do only once. -Martin From stefan@aaa-sec.com Tue Nov 24 07:46:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117013A6A85 for ; Tue, 24 Nov 2009 07:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p56l0zy0KNiY for ; Tue, 24 Nov 2009 07:46:57 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 431763A6A80 for ; Tue, 24 Nov 2009 07:46:56 -0800 (PST) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2406528DA46 for ; Tue, 24 Nov 2009 16:46:56 +0100 (CET) Received: (qmail 60897 invoked from network); 24 Nov 2009 15:46:49 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Nov 2009 15:46:49 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 16:46:46 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: [TLS] Other S->C signaling methods Thread-Index: AcptHVO/hu8dNIpPY0CGsh3E756/6w== In-Reply-To: <200911241532.nAOFWoQh005340@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:46:58 -0000 Martin, On 09-11-24 4:32 PM, "Martin Rex" wrote: > But in practice, we want the fix to change as little as possible > and work in all existing usage scenarios. That certainly includes > those scenarios that are actively using TLS extensions. > > IMHO, that means we should make it fit into SSLv3 ServerHello > (which is a part of ExtendedServerHello) Not saying that you are wrong, could you motivate this a bit further. E.g. Why would it be easier (and less ugly) for a server/client to mix with the protocol version bits versus sending and parse a new small handshake message after the server hello? /Stefan From mrex@sap.com Tue Nov 24 08:16:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2A828C138 for ; Tue, 24 Nov 2009 08:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Mc9IKGbAH7Lf for ; Tue, 24 Nov 2009 08:16:26 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B566C28C135 for ; Tue, 24 Nov 2009 08:16:24 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAOGGHoF008265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 17:16:17 +0100 (MET) From: Martin Rex Message-Id: <200911241616.nAOGGFPk007866@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Tue, 24 Nov 2009 17:16:09 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Nov 24, 9 04:46:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:16:27 -0000 Stefan Santesson wrote: > > On 09-11-24 4:32 PM, "Martin Rex" wrote: > > > But in practice, we want the fix to change as little as possible > > and work in all existing usage scenarios. That certainly includes > > those scenarios that are actively using TLS extensions. > > > > IMHO, that means we should make it fit into SSLv3 ServerHello > > (which is a part of ExtendedServerHello) > > Not saying that you are wrong, could you motivate this a bit further. > > E.g. Why would it be easier (and less ugly) for a server/client to mix with > the protocol version bits versus sending and parse a new small handshake > message after the server hello? The addition of a new handshake message will likely impact the entire protocol state engine (OpenSSL architecture comes to mind), one might have to change the record layer, the message pipelining, it will become visible in the per-handshake-message callbacks. There may be a lot of other things I haven't thought of, but I'm really worried that this may break assumptions of callers of the TLS applications. I'm worried about breaking existing usage scenarios and consumers of TLS, because that may be a real problem in getting a patch deployed quickly. When changing data in the _network_encoding_ of a handshake message only, then it should be fairly easy to contain the changes to that code that composes this particular handshake message (server-side for ServerHello) and that code that parses this particular handshake message (client-side for ServerHello). And I firmly believe, the negotiation of SSL/TLS should happen inside ClientHello & ServerHello (or ExtendedClientHello&ExtendedServerHello). Personally, I'm much less considerate to middle boxes like firewalls that might have to adapt slightly if they're totally entangled with each and every bit of a ServerHello. These beast are likely to be still under maintenance, and they have to adapt all the time. -Martin From mrex@sap.com Tue Nov 24 08:35:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732F43A6AB6 for ; Tue, 24 Nov 2009 08:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.106, 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 LsVNwRF0ycIH for ; Tue, 24 Nov 2009 08:35:25 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 7319D3A6B1F for ; Tue, 24 Nov 2009 08:35:25 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAOGZCPO024197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 17:35:12 +0100 (MET) From: Martin Rex Message-Id: <200911241634.nAOGYsEt009318@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Tue, 24 Nov 2009 17:34:43 +0100 (MET) In-Reply-To: from "Yoav Nir" at Nov 24, 9 10:42:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:35:26 -0000 Yoav Nir wrote: > > I see that you use the protocol field for the S->C signaling, but at > least it's on the ServerHello rather than the handshake record header. We need to transfer just one single bit of information within ServerHello. > > Still, I'm worried about firewall/IPS/IDS devices that deep-inspect > protocols. A server answering with the wrong SSL version may just > be "weird" enough for the middlebox to drop the connection. > I'm not at that side of Check Point, but I know that much of the > protection code is not targeted at a particular attack, but just > performs a sanity check on the protocols. We are already facing sufficient challenges with TLS server that do not like protocol version numbers above {03,01} in ClientHello.client_version. I hope that builders of deep-inspecting firewalls are not going to cause additional headaches by doing something obviously unwise like restricting the TLS protocol version from evolving. If those firewalls are concerned about security, they should be adding filters for traditional renegotiation--and when doing that, they could fix such obvious flaws on the way. -Martin From marsh@extendedsubset.com Tue Nov 24 08:36:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36B128C10D for ; Tue, 24 Nov 2009 08:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 NSxdOlBcgKf6 for ; Tue, 24 Nov 2009 08:36:35 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 0DFD53A689A for ; Tue, 24 Nov 2009 08:36:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NCyNR-0003el-0g; Tue, 24 Nov 2009 16:36:29 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DA0CA6678; Tue, 24 Nov 2009 16:36:26 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19zHO1g2/BBsYG17XLqY14YmxdETC2LVGU= Message-ID: <4B0C0B85.5020300@extendedsubset.com> Date: Tue, 24 Nov 2009 10:36:21 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: IETF TLS Working Group References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:36:35 -0000 Stefan Santesson wrote: > > And this is also it's weakness as pointed out in previous mails, as it > allows bad implementations of the fix to appear good. I'm very sympathetic to the idea of "fail safe" design. However, it's impossible for a spec to defend itself against an implementor determined to do it badly! So when evaluating the relative benefits of the proposals (under the current circumstances) I would consider goof-resistance to be a nice bonus, but not a primary factor. Everyone can expect testing tools to be available for the well- and ill-intentioned alike (e.g. Metasploit). That should help implementors get it right. - Marsh From mrex@sap.com Tue Nov 24 08:41:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4603A6930 for ; Tue, 24 Nov 2009 08:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=0.104, 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 GYn3h3DZy0FT for ; Tue, 24 Nov 2009 08:41:29 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 7387F3A67E9 for ; Tue, 24 Nov 2009 08:41:29 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAOGfLwf002616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 17:41:21 +0100 (MET) From: Martin Rex Message-Id: <200911241641.nAOGfCiK009546@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Tue, 24 Nov 2009 17:41:03 +0100 (MET) In-Reply-To: <4B0B919A.8060303@extendedsubset.com> from "Marsh Ray" at Nov 24, 9 01:56:10 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:41:30 -0000 Marsh Ray wrote: > > Ben Laurie wrote: > > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: > >> It is the golden rule of the IETF > >> "be liberal in what you accept, be conservative in what you send out" > > > > That has proved to be a less-than-great idea, particularly in > > protocols where you care about security, which is to say, all of them. > > Another way to think about it: any time a receiver is being liberal in > what it accepts the protocol is depending on undefined behavior. There is a difference in what you accept (what your parser accepts) and what part of that you actually use/believe/rely on. That quote is about interoperability, and it against building flawed assumptions into your code all over the place that will blow up if the protocol is changed in a way that fits into the spec, but makes flawed assumptions cause all sorts of problems. A lot of "secure time servers" actually source their time from a radio signal that is unprotected (simple and old protocols). I don't know how much sanity checks they do. A chain is only as strong as its weakest link. -Martin From rwilliams@certicom.com Tue Nov 24 08:41:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1273A67E9 for ; Tue, 24 Nov 2009 08:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 dWvMtwLIYjfv for ; Tue, 24 Nov 2009 08:41:44 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 2F0283A67E4 for ; Tue, 24 Nov 2009 08:41:44 -0800 (PST) X-AuditID: 0a401fcb-b7b71ae000002562-c5-4b0c0cc274e6 Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 70.FC.09570.2CC0C0B4; Tue, 24 Nov 2009 11:41:39 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 11:41:38 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Tue, 24 Nov 2009 11:41:09 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC40278B7D4@XCH57YKF.rim.net> In-Reply-To: <200911241634.nAOGYsEt009318@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted Thread-Index: AcptJE3Sw01/ZRsRSG+vyc3e0C8FYgAAGrFw References: from "YoavNir" at Nov 24, 9 10:42:12 am <200911241634.nAOGYsEt009318@fs4113.wdf.sap.corp> From: "Rob P Williams" To: , "Yoav Nir" X-OriginalArrivalTime: 24 Nov 2009 16:41:38.0414 (UTC) FILETIME=[FE2DB8E0:01CA6D24] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:41:45 -0000 > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex > Sent: Tuesday, November 24, 2009 11:35 AM > To: Yoav Nir > Cc: tls@ietf.org > Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted > > Yoav Nir wrote: > > > > I see that you use the protocol field for the S->C signaling, but at > > least it's on the ServerHello rather than the handshake record header. > > We need to transfer just one single bit of information within ServerHello. > > > > > Still, I'm worried about firewall/IPS/IDS devices that deep-inspect > > protocols. A server answering with the wrong SSL version may just > > be "weird" enough for the middlebox to drop the connection. > > I'm not at that side of Check Point, but I know that much of the > > protection code is not targeted at a particular attack, but just > > performs a sanity check on the protocols. > > We are already facing sufficient challenges with TLS server > that do not like protocol version numbers above {03,01} in > ClientHello.client_version. > > I hope that builders of deep-inspecting firewalls are not > going to cause additional headaches by doing something > obviously unwise like restricting the TLS protocol version > from evolving. > > If those firewalls are concerned about security, they should > be adding filters for traditional renegotiation--and when > doing that, they could fix such obvious flaws on the way. I hope those firewalls cannot read our encrypted renegotiation taking place to filter it. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From mrex@sap.com Tue Nov 24 08:47:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8DA3A6A60 for ; Tue, 24 Nov 2009 08:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.103, 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 A5UPWv2CNkKf for ; Tue, 24 Nov 2009 08:47:17 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 23B3F3A68CB for ; Tue, 24 Nov 2009 08:47:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAOGl2kv002143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 17:47:02 +0100 (MET) From: Martin Rex Message-Id: <200911241646.nAOGkaQP009757@fs4113.wdf.sap.corp> To: rwilliams@certicom.com (Rob P Williams) Date: Tue, 24 Nov 2009 17:46:09 +0100 (MET) In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC40278B7D4@XCH57YKF.rim.net> from "Rob P Williams" at Nov 24, 9 11:41:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:47:17 -0000 Rob P Williams wrote: > > > We are already facing sufficient challenges with TLS server > > that do not like protocol version numbers above {03,01} in > > ClientHello.client_version. > > > > I hope that builders of deep-inspecting firewalls are not > > going to cause additional headaches by doing something > > obviously unwise like restricting the TLS protocol version > > from evolving. > > > > If those firewalls are concerned about security, they should > > be adding filters for traditional renegotiation--and when > > doing that, they could fix such obvious flaws on the way. > > I hope those firewalls cannot read our encrypted renegotiation taking > place to filter it. The content_types are visible in the clear at the record layer, so the firewalls will see handshake blobs flying by, and they can recognize the ChangeCipherSpec message by their ContentType, because it is not a handshake message (only sent within a handshake). -Martin From mrex@sap.com Tue Nov 24 09:05:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27933A68DA for ; Tue, 24 Nov 2009 09:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.102, 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 9LUNzYmMIkbe for ; Tue, 24 Nov 2009 09:05:15 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 8AC8D3A68C4 for ; Tue, 24 Nov 2009 09:05:15 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAOH53sB005162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 18:05:03 +0100 (MET) From: Martin Rex Message-Id: <200911241704.nAOH4spL010892@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Tue, 24 Nov 2009 18:04:49 +0100 (MET) In-Reply-To: <23ACBC75-62CC-4521-8BB5-A3D425C07204@checkpoint.com> from "Yoav Nir" at Nov 24, 9 02:02:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:05:16 -0000 Yoav Nir wrote: > > I've said several times that I prefer Martin's approach. > It's just that I'd prefer a more subtle way for the S->C > signalling (like something in the random or GMT) I realized that my description of the details of the change is "a little confusing" to put it mildly. I'm going to clean up the description my I-D to make it consitent and much more readable. It's strange. Seems I was slightly tired when I submitted the document, because I didn't notice this myself that day. > > An unknown ciphersuite is weird, but in a world with GOST and Camelia, > you can't drop TLS handshakes based on that. > > A magic timestamp is weird, but we already have implementations > randomizing this field, so IDSs are already "trained" to ignore this. > > Unknown extensions are a new kind of weirdness, but since they're > allowed by the protocol, I don't expect much trouble there either. > > Replying with version 131.1 to a request from version 3.1 is a > clear protocol violation that may get noticed. I beg to differ! the meaning of a server_version value of 131,1 is undefined for implementations of RFC2246, RFC4346 and RFC5246. So is the modified renegotiation handshake that we are defining. Same applies to the semantics of TLS extension RI. For the purpose of security, we have to make a backwards-incompatible breaking change in order to tell the peer that an implementation does not contain the vulnerability that is in RFC2246, RFC4346 and RFC5246. Which clients will get to see this change? only those, that have explicitly asked for it by including the special cipher suite ID in the ClientHello. plus those that are under attack from an MitM (but there's little we can do for them anyway, the attacker may feed them arbitrary data of his choice. -Martin From rwilliams@certicom.com Tue Nov 24 09:09:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313903A689C for ; Tue, 24 Nov 2009 09:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 n4Tw-M8Gs1ni for ; Tue, 24 Nov 2009 09:09:21 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id E8A1B3A67A2 for ; Tue, 24 Nov 2009 09:09:20 -0800 (PST) X-AuditID: 0a666446-b7b5eae0000003bc-46-4b0c133bfab8 Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 31.E3.00956.B331C0B4; Tue, 24 Nov 2009 12:09:15 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 12:09:15 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Tue, 24 Nov 2009 12:09:06 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC40278B857@XCH57YKF.rim.net> In-Reply-To: <200911241646.nAOGkaQP009757@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted Thread-Index: AcptJcChFQKt4OdQSL23F0zSaMHxNAAAirfQ References: <7E1DF37F1F42AB4E877E492C308E6AC40278B7D4@XCH57YKF.rim.net> from "Rob P Williams" at Nov 24, 9 11:41:09 am <200911241646.nAOGkaQP009757@fs4113.wdf.sap.corp> From: "Rob P Williams" To: X-OriginalArrivalTime: 24 Nov 2009 17:09:15.0153 (UTC) FILETIME=[D9AC0810:01CA6D28] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:09:22 -0000 'hope' was the wrong word. I meant 'wish'. Perhaps wish is also the wrong word. Why the record type was left exposed? As you say, you can see what is going past. You can see alerts. Why wasn't there a record type 'encrypted record'? -----Original Message----- From: Martin Rex [mailto:mrex@sap.com] Sent: Tuesday, November 24, 2009 11:46 AM To: Rob P Williams Cc: mrex@sap.com; ynir@checkpoint.com; tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted Rob P Williams wrote: > > > We are already facing sufficient challenges with TLS server > > that do not like protocol version numbers above {03,01} in > > ClientHello.client_version. > > > > I hope that builders of deep-inspecting firewalls are not > > going to cause additional headaches by doing something > > obviously unwise like restricting the TLS protocol version > > from evolving. > > > > If those firewalls are concerned about security, they should > > be adding filters for traditional renegotiation--and when > > doing that, they could fix such obvious flaws on the way. > > I hope those firewalls cannot read our encrypted renegotiation taking > place to filter it. The content_types are visible in the clear at the record layer, so the firewalls will see handshake blobs flying by, and they can recognize the ChangeCipherSpec message by their ContentType, because it is not a handshake message (only sent within a handshake). -Martin ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From mrex@sap.com Tue Nov 24 09:31:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050063A6359 for ; Tue, 24 Nov 2009 09:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 1vlOiCv+Ikg6 for ; Tue, 24 Nov 2009 09:30:59 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5899D3A68DA for ; Tue, 24 Nov 2009 09:30:54 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAOHUfnG007445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 18:30:41 +0100 (MET) From: Martin Rex Message-Id: <200911241730.nAOHUXXD012421@fs4113.wdf.sap.corp> To: rwilliams@certicom.com (Rob P Williams) Date: Tue, 24 Nov 2009 18:30:28 +0100 (MET) In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC40278B857@XCH57YKF.rim.net> from "Rob P Williams" at Nov 24, 9 12:09:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:31:00 -0000 Rob P Williams wrote: > > Why the record type was left exposed? > > Why wasn't there a record type 'encrypted record'? *I* don't know the history and rationale behind this. It was part of Netscape's SSLv3. > > As you say, you can see what is going past. You can see alerts. You can see the ContentTypes of the records, even when the contents are encrypted. You can see the ContentType alert, you can not see the alert itself (in wireshark traces, it shows up as encrypted alert if the alert happens after the first ChangeCipherSpec). -Martin From mrex@sap.com Tue Nov 24 09:52:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2626A3A6859 for ; Tue, 24 Nov 2009 09:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 AyPn2UbVCRnC for ; Tue, 24 Nov 2009 09:52:08 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0EF973A67A2 for ; Tue, 24 Nov 2009 09:52:07 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAOHpwgN001931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 18:51:58 +0100 (MET) From: Martin Rex Message-Id: <200911241751.nAOHpth2013883@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Tue, 24 Nov 2009 18:51:27 +0100 (MET) In-Reply-To: <4B0B6AE6.8040606@bolyard.me> from "Nelson B Bolyard" at Nov 23, 9 09:11:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:52:09 -0000 Nelson B Bolyard wrote: > > It does not change the finished message, or the computation of the handshake > hashes. All remain 100% computable from the inputs to the > present handshake. That's exactly what I do, too. TLS extension RI has the same additional input to the renegotiation handshake as my proposal. That is a requirement to make the renegotiation secure. > > > Great! So you will not have a problem with my proposal either, > > because mine does not change the finished message computation > > either. > > > > http://www.ietf.org/mail-archive/web/tls/current/msg04194.html > > Your change makes the handshake hash (and hence the finished) no longer > computable purely from the input to the current handshake. Oh yes, it does! The finished messages from the previous handshake are definitely input to the current handshake. In my proposal I just don't send the previous handshake messages over the wire one more time, because there is absolutely no need to (there were already exchanged in the previous handshake), and it results in a failsafe design. The finished message calculation includes the master secret, and that includes public key operations, so deriving the finished messages directly from what goes over the wire has _never_ been possible with TLS. > > > Just that directly hashing them is less work > > It's a bigger code change, which is more to get wrong. > Where have I heard that argument used before? It is pretty difficult to imagine a software implementation where adding the verify_data directly to the handshake message hash to result in more code. It would have to be spaghetti code where the handshake message hash is directly hardwired into the record layer behind decryption, and only "reset_handshake_message_hash" and "finalize_handshake_message_hash" implemented as seperately callable functions, but not "add_to_handshake_message_hash(handle, buffer,len)" -Martin From mrex@sap.com Tue Nov 24 09:57:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2183A6955 for ; Tue, 24 Nov 2009 09:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.15 X-Spam-Level: X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=0.099, 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 uu21uYRbfSon for ; Tue, 24 Nov 2009 09:57:46 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 975C53A6859 for ; Tue, 24 Nov 2009 09:57:46 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAOHvbRk008950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 18:57:37 +0100 (MET) From: Martin Rex Message-Id: <200911241757.nAOHvaEB014116@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Tue, 24 Nov 2009 18:57:30 +0100 (MET) In-Reply-To: <4B0B6AE6.8040606@bolyard.me> from "Nelson B Bolyard" at Nov 23, 9 09:11:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:57:47 -0000 Nelson B Bolyard wrote: > > > From a cryptograpic standpoint, adding the verify_data into > > the handshake message hashes without sending them over > > the network is equivalent to adding them to the handshake > > messages itself, sending them over the wire and having > > to compare the values explicitly. > > > > Just that directly hashing them is less work > > It's a bigger code change, which is more to get wrong. Besides being less code, it is really hard to get this one wrong, because regular interop tests with client and servers will tell you exactly when you got it wrong. Different to TLS extension RI, you do not Code Review or Penetration testing to ensure that you got it correct, it will do this all by itself. If you're worried you get this part wrong, you definitely should not contemplate TLS extension RI. -Martin From mike-list@pobox.com Tue Nov 24 10:29:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B743728C13E for ; Tue, 24 Nov 2009 10:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm0fWq--OJ8P for ; Tue, 24 Nov 2009 10:29:00 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id A51E128C13B for ; Tue, 24 Nov 2009 10:29:00 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D82C4820E6 for ; Tue, 24 Nov 2009 13:28:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Att9haHHV+Ru zO8ViO4+hFV3hHk=; b=fZZWz4BR6M9xuKrxjQGG7tLLvhYUqWi7AMbPLQrdlyZE uIDcZThtuvtIxrJEtG97L3luW/BkJO7xRtO6uSFwEgKYFm2KPA4KnPp5o5dtaHua yRBfaL9JQQImH5CXjOQ0crrfGgYTaCevrVhFBmXsTe/SEzoMjW2M4NJFx4XE7S4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=caM4U6 gRzqplY/5GHbeeiJZQ50sUCTaWr+IvmU2CSLwDozggMmx67If1cb76Zf/0yWU0v3 t2OXnnCVeoZYmBHzhc7u9unhhWNes751ub36z7qywNirDUarkNaZtCIq7WLsuWVk x2UH37ugjORGXS83LSYYDMRZgtpQTVAaQOtlI= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D50E7820E4 for ; Tue, 24 Nov 2009 13:28:55 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 42242820E2 for ; Tue, 24 Nov 2009 13:28:55 -0500 (EST) Message-ID: <4B0C262F.2010303@pobox.com> Date: Tue, 24 Nov 2009 10:30:07 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: IETF TLS Working Group References: <200911222221.nAMMLl91022142@fs4113.wdf.sap.corp> <4B09ECAB.7050205@bolyard.me> <4B09F3C0.9060704@pobox.com> <4B09FC30.4070107@bolyard.me> <4B0A03C4.7030504@pobox.com> <4B0A0743.5000804@bolyard.me> <4B0AA334.4030901@pobox.com> <4B0AF05F.9000408@bolyard.me> In-Reply-To: <4B0AF05F.9000408@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 39724646-D927-11DE-9EE7-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:29:01 -0000 [ignoring the fact that a private message was forwarded to the list (and edited to boot)....] No, you are missing the point. The fact that RI gets the verify_data into the next handshake hash does NOT improve security. The added security is only the result of manually checking that what was received was correct. This means that now we require 2 checks, that RI is correct and that Finished is correct. It would be easy for an implementor to miss. I know this because I almost missed it! After getting the mechanics of sending and receiving the extension correct, I was like, "Oh, sh*t! I forgot to check that it was correct!" If I can mess this up, how can you expect poor maintenance programmers to get it right? The alternative I proposed here[*] requires only that the Finished message continue to be checked as it is today. I can see how you would like to not change the Finished calculation unless the version is changed. The problem with that is we have 4 versions to patch and there can be only one successor version (e.g. TLS 1.3). Mike [*] http://www.ietf.org/mail-archive/web/tls/current/msg04600.html Nelson B Bolyard wrote: > On 2009-11-23 06:59 PST, Michael D'Errico wrote: > >> I proposed a change to RI in another message that: >> >> - makes the extension empty in both directions on every handshake >> - changes the Finished calc. in some way (there are various ways to >> do it and I don't care which is chosen) > >> What I don't like about the current RI proposal is that it uses extensions >> more than just as a signaling mechanism; you actually have to craft them >> in both directions and extract the data at the other end. Plus as I pointed >> out, you need to actually check that the data received is correct. > > Checking that data is correct is a very large part of the value of security > software. > >> If you agree that this is better/simpler than the current RI proposal, I'd >> appreciate it if you would send a note to the list enumerating these >> benefits. > > I disagree with is emphatically. I disagree with changing the definition of > the finished messages without changing the protocol version number. > The IMPORTANT thing that RI accomplishes is that it gets the needed > information included in the Finished message computations WITHOUT changing > the definition of the Finished message computations. That is precisely > its strength! That is precisely why I support it. From marsh@extendedsubset.com Tue Nov 24 11:59:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC8628C13B for ; Tue, 24 Nov 2009 11:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 DWzHULCaWpZY for ; Tue, 24 Nov 2009 11:59:35 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A39C728C13F for ; Tue, 24 Nov 2009 11:59:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1ND1Xu-00085f-LJ; Tue, 24 Nov 2009 19:59:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2C3EB603A; Tue, 24 Nov 2009 19:59:28 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/eluj+YiWYrafxqIn3dvylZqgR3G+IzY4= Message-ID: <4B0C3B1A.8060007@extendedsubset.com> Date: Tue, 24 Nov 2009 13:59:22 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911241417.nAOEHScP000631@fs4113.wdf.sap.corp> In-Reply-To: <200911241417.nAOEHScP000631@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:59:36 -0000 Martin Rex wrote: > > There is much less contention on the server_version.major, > that hasn't seen a lot of change for a while. :) How about you set the highest bit in the version minor field? I have seen lots of code over the years programmed to break when the major version changes but tolerate increases in the minor version. A change to the major version of a protocol is sometimes meant to signal that the changes are non-backwards-compatible, but bumping the minor version means they are. I suspect you might break less packet inspection code by manipulating the minor version rather than the major version. - Marsh From marsh@extendedsubset.com Tue Nov 24 12:43:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AEE13A6973 for ; Tue, 24 Nov 2009 12:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 4Z6WtUbjhZii for ; Tue, 24 Nov 2009 12:43:56 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 62CDA3A67C0 for ; Tue, 24 Nov 2009 12:43:56 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1ND2Ep-000J5U-Gv; Tue, 24 Nov 2009 20:43:51 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A2FB0603A; Tue, 24 Nov 2009 20:43:49 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/SFEUwQFuvFErMK49ykjQPLSc5DKaTks0= Message-ID: <4B0C4580.2060403@extendedsubset.com> Date: Tue, 24 Nov 2009 14:43:44 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, yaronf@checkpoint.com Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 20:43:57 -0000 Pasi.Eronen@nokia.com wrote: > Earlier Eric noted that if no application data is exchanged between the > initial and renegotiation handshake (i.e. no application data is sent > using the 1st session), this would be safe even without protocol > changes. Should this be included in this section, too? In order for that scenario to be 'safe' we would need to find some language in the TLS spec, there since the beginning, which says that an application MUST NOT attribute any semantics to the successful authentication of the remote party. I don't believe the spec has any such language. There is probably some application out there which interprets a connection from an authenticated client (or to an authenticated server) as an "event" with real semantics. Using SSH as an analogy, sometimes a login shell is set to, say, a backup program. Commands get launched when the user authenticates. Back with TLS, Microsoft IIS, for example, has a client-certificate-to-user mapping facility. It's certainly possible that the connection from such authenticated clients could trigger certain "non-idempotent" activities, even if just adding false log records. - Marsh From mrex@sap.com Tue Nov 24 14:19:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494813A680C for ; Tue, 24 Nov 2009 14:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.098, 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 EwTrCkqZWKAL for ; Tue, 24 Nov 2009 14:18:59 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2997D3A6849 for ; Tue, 24 Nov 2009 14:18:58 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAOMIpgx019913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 23:18:51 +0100 (MET) From: Martin Rex Message-Id: <200911242218.nAOMIoEW006307@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Tue, 24 Nov 2009 23:18:50 +0100 (MET) In-Reply-To: <4B0C3B1A.8060007@extendedsubset.com> from "Marsh Ray" at Nov 24, 9 01:59:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:19:00 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > > > There is much less contention on the server_version.major, > > that hasn't seen a lot of change for a while. :) > > How about you set the highest bit in the version minor field? If that would make the proposal more acceptable, *I* would not have a problem with it. I know that Mike prefers the highest bit of the minor. > > I have seen lots of code over the years programmed to break when the > major version changes but tolerate increases in the minor version. A > change to the major version of a protocol is sometimes meant to signal > that the changes are non-backwards-compatible, but bumping the minor > version means they are. Frankly, this is exactly why I'm advocating the use of the major. I don't want the code to make version arithmetic when the signal bit is still on. And I know code that uses ==SSL_VERSION_MAJOR in several places. As it would be easier if they shaved the version number off when parsing ServerHello on the client, they are more likely to do so rather have to change a dozen ==SSL_VERSION_MAJOR. I'm much less sure about server_version.minor. They might be much more tempted to leave the bit on and then it starts appearing in a lot of other places of the code that are not reallly prepared to handle it. > > I suspect you might break less packet inspection code by manipulating > the minor version rather than the major version. As I've previously pointed out, I much more concerned about breaking apps on top of TLS and interoperability with the installed base that of breaking the packet inspecting stuff. The latter is going to adapt much more quickly then the internet will deploy our fix. We have significantly more 6-year old SSL/TLS implementations around than 6-year old AV- and Packet-Insepecting-Firewall equipment--that stuff doesn't make much sense if it is not constantly updated to the most recent threats. -Martin From marsh@extendedsubset.com Tue Nov 24 14:55:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF7E3A68F4 for ; Tue, 24 Nov 2009 14:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 oNGR1QTp0hzA for ; Tue, 24 Nov 2009 14:55:06 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 9B1183A680C for ; Tue, 24 Nov 2009 14:55:06 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1ND4Hl-0009BI-OQ for tls@ietf.org; Tue, 24 Nov 2009 22:55:01 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 83395603A for ; Tue, 24 Nov 2009 22:55:00 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+5c5gV6+NEgJ31n7h9PLcVUaEbxouw4Fw= Message-ID: <4B0C6444.2030500@extendedsubset.com> Date: Tue, 24 Nov 2009 16:55:00 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <6b9359640911241414o1468616ajfdd0840f84e2cbc7@mail.gmail.com> In-Reply-To: <6b9359640911241414o1468616ajfdd0840f84e2cbc7@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Thoughts on the protocol and backward-compatibility (was: Server-only solution - proposed text) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:55:07 -0000 Kyle Hamilton wrote: > > I still want the ability to negotiate using an ephemeral suite, and > only then (in the > protected-from-eavesdropping-but-not-yet-authenticated channel) offer > the certificates. I don't see anything wrong with that in principle (but it doesn't do what you want, see below). In practice you may end up retroactively authenticating the anonymous data that was sent earlier. Whether or not that's ever a valid thing to do was a key point that went unspecified in the SSLv3 and TLS specs. It seems that with a retroactive authentication scheme, otherwise minor oversights usually result in exploitable security holes. > In my view, this is a rather serious > information-disclosure vulnerability in the original protocol, where > the Certificate messages are sent before ChangeCipherSuite. In theory, the client certificate is "public" info. In practice, it has all kinds of things in there that admins would prefer were encrypted. > This is > simply not possible without renegotiation. Even with perfect server-initiated renegotiation, your scheme fails to prevent MitM from getting the client certificate if he wants it. > The TLS library has the ability to detect when application data has > come in -- and one of the ways to mitigate this might be for the TLS > library to maintain an additional flag Keep in mind that each additional flag has the potential to double the testing requirements for implementors. - Marsh From aerowolf@gmail.com Tue Nov 24 15:39:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC22C3A67E3 for ; Tue, 24 Nov 2009 15:39:46 -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 2Mj8CVZMdWQX for ; Tue, 24 Nov 2009 15:39:45 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id D67B93A67C1 for ; Tue, 24 Nov 2009 15:39:45 -0800 (PST) Received: by pwi6 with SMTP id 6so4874593pwi.29 for ; Tue, 24 Nov 2009 15:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hpjrEUB+xLLlE1M3WABHzy0z7N8BBBehVMjNS16N5Gs=; b=YaMoZ7smaQCvqHbYv7ITtQltKBLt1MZ+eXnZlDG4s7UMJm2RKMBc9Ul7uSnjc9/kFK efAIN7PTiJ4xApT5950jyglQ9XwQy0iqORifo5qjHpZQWidlJDZghmcS3n2Hyr4blT/t 60sIacv8QeMx1j7N3Fpd/QBPi4YToDvKMKOL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YQLzzCLbJ9CKxbRNfXk2gWw1Uv23aQhV+av607R/z0dkcX2ATLQnNVs3LOUzd/6mhp iocKhb+Nvhrk6an6d4e6el1zA5hrkVsBxo5Cdj/bkeh2NbZzBIdBh+f0/e0zEpnpQLZ4 nnH83ORpH0LnDadU7iUJjCGsK2ot1FuSJ6IR8= MIME-Version: 1.0 Received: by 10.143.27.41 with SMTP id e41mr739066wfj.218.1259105978641; Tue, 24 Nov 2009 15:39:38 -0800 (PST) In-Reply-To: <4B0C6444.2030500@extendedsubset.com> References: <6b9359640911241414o1468616ajfdd0840f84e2cbc7@mail.gmail.com> <4B0C6444.2030500@extendedsubset.com> Date: Tue, 24 Nov 2009 15:39:38 -0800 Message-ID: <6b9359640911241539n6fecc68dlbb3eab96b10461ba@mail.gmail.com> From: Kyle Hamilton To: Marsh Ray Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 24 Nov 2009 15:49:13 -0800 Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on the protocol and backward-compatibility (was: Server-only solution - proposed text) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:41:20 -0000 I'm aware that my proposal doesn't offer complete protection from an MITM. What it does provide is protection that the MITM can't see what's there. Now, if instead of presenting the certificate, it provided the public key and proof that the public key matches the private key that it has, then the channel would be 'bound' to that public key. The proof of the keypair could also include a nonce that the client has to respond with, with its own keypair. Once the channel's bound to a first-order identity (the public/private key pair), then it can be authenticated via CA-issued certificates that contain the same public keys in use. (Really, I prefer protocols that have "perfect forward secrecy", but TLS seems to have been built without that concept in mind, as far as the certificate presentment and usage goes. It might be useful to present a certificate and validate it inside the channel, without having to deal with a full handshake -- allow the server to send ServerCertificate at any time, and then validate it, without changing any of the channel parameters.) I think that it was decided not to do anything like this because it increases the number of round trips on the network, though I don't think the number of asymmetric operations would necessarily go up (client still needs to verify the key that the server provides, and client still needs to verify the certificate that the server provides -- and the same for the server, it needs to verify the key that the client provides and the cert that the client provides). I'm not certain, though, because I wasn't on the list at that point. I just want to make sure that renegotiation is still supported, because I need that function. So, I offer my ideas on how to signal the server that the client knows how to use a modified Finished handshake. The only downside is that it takes some kind of extension to signal the client that the server knows how to do it, too. :P -Kyle H On Tue, Nov 24, 2009 at 2:55 PM, Marsh Ray wrote: > Kyle Hamilton wrote: >> >> I still want the ability to negotiate using an ephemeral suite, and >> only then (in the >> protected-from-eavesdropping-but-not-yet-authenticated channel) offer >> the certificates. > > I don't see anything wrong with that in principle (but it doesn't do > what you want, see below). In practice you may end up retroactively > authenticating the anonymous data that was sent earlier. Whether or not > that's ever a valid thing to do was a key point that went unspecified in > the SSLv3 and TLS specs. > > It seems that with a retroactive authentication scheme, otherwise minor > oversights usually result in exploitable security holes. > >> In my view, this is a rather serious >> information-disclosure vulnerability in the original protocol, where >> the Certificate messages are sent before ChangeCipherSuite. > > In theory, the client certificate is "public" info. > > In practice, it has all kinds of things in there that admins would > prefer were encrypted. > >> This is >> simply not possible without renegotiation. > > Even with perfect server-initiated renegotiation, your scheme fails to > prevent MitM from getting the client certificate if he wants it. > >> The TLS library has the ability to detect when application data has >> come in -- and one of the ways to mitigate this might be for the TLS >> library to maintain an additional flag > > Keep in mind that each additional flag has the potential to double the > testing requirements for implementors. > > - Marsh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From aerowolf@gmail.com Tue Nov 24 15:23:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8405D3A67C1 for ; Tue, 24 Nov 2009 15:23:07 -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 6qb5a1Ng3xo6 for ; Tue, 24 Nov 2009 15:23:06 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id AB2653A67AF for ; Tue, 24 Nov 2009 15:23:04 -0800 (PST) Received: by pzk6 with SMTP id 6so4907446pzk.29 for ; Tue, 24 Nov 2009 15:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=bvbALgrQQYQBFniR6BKG9Y27SSheZx/0f2M2bcGVP2Q=; b=YavCRvsPyhCCXkV0L6ZJUIvwNfsPwoWHXFZPQ4Fo97cvKRYnVs6Ic0q2I/eO2lAweE pajtfYDeLX4W44NqmnCNmUydnjEQY6BFdWYGiYXaMbm5due+rq4Mj0s2L6yveCWbuQ0G 75E/PAM1VtXS46NPOgW7V/RIiLE3f1KJfLVKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WmavWeqTwUF/2KYyo9jfsUXwrD1jJrSHBkgzgCXf1iTMPXounb7wW1tZj9O1FYt6jx TkwbmiWliaWj5U80BY6XzX8pLcfwNjJbDaGqZtXZMO/ICkJAtyQv2w6utZrOtCVxG72s GhX/622DANZGZ3dY+UKp2+1tyhBOULVkIp45g= MIME-Version: 1.0 Received: by 10.142.8.35 with SMTP id 35mr794548wfh.30.1259104977627; Tue, 24 Nov 2009 15:22:57 -0800 (PST) Date: Tue, 24 Nov 2009 15:22:57 -0800 Message-ID: <6b9359640911241522q6e31633bp3fd48bc2922c0cdf@mail.gmail.com> From: Kyle Hamilton To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 24 Nov 2009 15:49:13 -0800 Subject: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:41:36 -0000 I hadn't actually read this before I wrote my last message. It includes both of the aspects that I stated were necessary (a TLS extension and a magic cipher identifier), and I support it. 4.3.1: Clients which choose to fall back to an extensionless mode of operation MUST include the magic cipher suite [TBD] in any such handshake. Servers MUST reject any ClientHello which uses this cipher suite but does not include RI with a fatal "handshake_failure" alert. Because servers ordinarily ignore unknown cipher suites, this cipher suite can be added safely on any handshake, thus allowing detection and prevention of the MITM attack described above. This is absolutely essential. TLS extensions exist, but SSL 3 is still commonly used. There's no reason why SSL 3 shouldn't benefit from anything that happens after-the-fact, even though it was never an actual IETF protocol. The only issue I see is... we've got an issue in signalling back to the client that it knows how to do the updated handshake. Would a slightly modified HelloRequest do it? -Kyle H From aerowolf@gmail.com Tue Nov 24 14:15:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BA83A6819 for ; Tue, 24 Nov 2009 14:15:01 -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 AHiiRik3+oDy for ; Tue, 24 Nov 2009 14:15:00 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 8317B3A680C for ; Tue, 24 Nov 2009 14:15:00 -0800 (PST) Received: by pzk6 with SMTP id 6so4871949pzk.29 for ; Tue, 24 Nov 2009 14:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=KNU22gqckwGCr+OsWdid7sanB1lS0VSj1kZdtervCcU=; b=DfTZviw7XV4yhHuKKO25OI0njwI96KFv2mDUiVkO+aakozKfOgGU+NxOoSsuSwgpWS FXKxOJNDZRMBC8uZ2rWesG1bPTG8wZYsvn2Gw1I3GMZuDIFyCo7SedAT8PHLVuc9gJSY AEyBYlfNVufwmG9PkbQHewIHSWeK1OReFBUA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Jl1QAQj7/c0JYty44W5BYiVhrZ5EaB8rrM8RwpPTjZ0pAygl0tFCO5tv7lCDYNVwtd EOgbJ63S5KPCwpslhXR23IJy6gyjzVdzEap/vfC/qE31S9N4ZPdXQDKABRUPUUp6iyLg g2bUZ9Zl2whHaX68escjK/k+7KQ3TqIIXHaZI= MIME-Version: 1.0 Received: by 10.142.119.20 with SMTP id r20mr730581wfc.303.1259100893465; Tue, 24 Nov 2009 14:14:53 -0800 (PST) Date: Tue, 24 Nov 2009 14:14:53 -0800 Message-ID: <6b9359640911241414o1468616ajfdd0840f84e2cbc7@mail.gmail.com> From: Kyle Hamilton To: Marsh Ray Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 24 Nov 2009 15:49:13 -0800 Cc: tls@ietf.org, yaronf@checkpoint.com Subject: [TLS] Thoughts on the protocol and backward-compatibility (was: Server-only solution - proposed text) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:44:32 -0000 On Tue, Nov 24, 2009 at 12:43 PM, Marsh Ray wrote: > Pasi.Eronen@nokia.com wrote: >> Earlier Eric noted that if no application data is exchanged between the >> initial and renegotiation handshake (i.e. no application data is sent >> using the 1st session), this would be safe even without protocol >> changes. Should this be included in this section, too? > > In order for that scenario to be 'safe' we would need to find some > language in the TLS spec, there since the beginning, which says that an > application MUST NOT attribute any semantics to the successful > authentication of the remote party. I don't believe the spec has any > such language. > > There is probably some application out there which interprets a > connection from an authenticated client (or to an authenticated server) > as an "event" with real semantics. > > Using SSH as an analogy, sometimes a login shell is set to, say, a > backup program. Commands get launched when the user authenticates. > > Back with TLS, Microsoft IIS, for example, has a > client-certificate-to-user mapping facility. It's certainly possible > that the connection from such authenticated clients could trigger > certain "non-idempotent" activities, even if just adding false log records. > > - Marsh I still want the ability to negotiate using an ephemeral suite, and only then (in the protected-from-eavesdropping-but-not-yet-authenticated channel) offer the certificates. In my view, this is a rather serious information-disclosure vulnerability in the original protocol, where the Certificate messages are sent before ChangeCipherSuite. This is simply not possible without renegotiation. The TLS library has the ability to detect when application data has come in -- and one of the ways to mitigate this might be for the TLS library to maintain an additional flag to prevent any application data from being sent out or accepted while a (re)negotiation is taking place. (There's already a requirement that application data not be sent with NULL-NULL-NULL, the initial state of the connection... and the one value which is illegal to negotiate.) If it does, the server could fatal-alert either unexpected_value, protocol_error, or insufficient_security. (If a patched server *requires* that the client be patched, insufficient_security or protocol_version would be appropriate.) Since there is already one magic value that must not be negotiated as a cipher suite, there's precedent to use that mechanism... and since this is a problem that affects all current versions of SSL3/TLS implementations, it is important that we not change the semantics of any of the messages that those implementations would normally see. This means that we must use the only extension mechanism defined in all SSL/TLS specifications -- the ability to add new cipher suites. Because of this, I see no way to avoid adding a second "it is an error if this suite is negotiated" tag to the cipher suite list. Thus, I support the idea of using a new magic value in the cipher list to indicate that a client has been patched (with the patch including "must not negotiate this cipher suite, but including it means that the server knows that the client can do the new renegotiation semantics"). I also support the idea of standards action with all due haste (once things are agreed upon) to update TLS 1.0, 1.1, and 1.2 with new semantics (and the Standards Action necessary to allocate a new cipher suite tag), with a recommendation to also update SSL 3.0 implementations. (SSL 2 is just bad in the first place, and I see no reason to try to improve it.) The only downside I see to this is the eventual possibility of branches of the protocol like Limewire did... using magic strings in what essentially amounted to the User-Agent string to identify extra capabilities. I believe that this problem is much more effectively and efficiently solved using TLS Extensions, so I am loath to add any additional magic values unless something else comes up that requires additional *retroactive* changes to the protocols that need to be signalled. (Using a cipher suite tag essentially leaves the protocol untouched for unpatched clients, and the workarounds on the server side ('no renegotiation' or 'server-initiated renegotiation only') will still work. If a server demands that the client be patched, I've discussed above what the appropriate response would appear to be, to my eyes (based on the definitions in RFC 5246 -- I haven't looked at earlier versions).) Once the signal has been sent by the client that it has been patched, both the patched client and server implementations could then branch into a different Finished calculation. I do like the idea of adding the hash from the last Finished message that the client sent -- initial state as all bits off -- to a renegotiated Finished handshake calculation. Since a client is not considered authenticated until the server has verified that the certificate is valid, the key to that certificate is held by the entity at the other end of the connection, and the ChangeCipherSpec and Finished messages check out... well, there's no worry of a client being improperly authenticated and triggering anything other than at most a 'bad login' attempt. Though I would prefer to see that one not be 'bad login' (since that could be a non-idempotent action that, for example, locks the user account), but 'attack detected'.) I also support the creation of a Renegotiation Indication extension, so that TLS servers that support extensions won't have to set a connection-context flag during processing of the cipher list. RI should also include the magic cipher code, or even have its tag *be* the magic 'patched cipher' code. (I do hate special-casing code -- in this case, during the cipher list processing, and then during the Finished message calculation -- but I don't really see much of a choice if we want to maintain some limited backward compatibility with the world that already exists, which the AD has stated is a priority.) -Kyle H From Nicolas.Williams@sun.com Tue Nov 24 16:13:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CDFB3A67BD for ; Tue, 24 Nov 2009 16:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.804 X-Spam-Level: X-Spam-Status: No, score=-5.804 tagged_above=-999 required=5 tests=[AWL=0.242, 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 EzcVVhTPcMZd for ; Tue, 24 Nov 2009 16:13:13 -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 7CDED3A672E for ; Tue, 24 Nov 2009 16:13:13 -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 nAP0D5lV024601 for ; Wed, 25 Nov 2009 00:13:09 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 nAP0D4fw004423 for ; Tue, 24 Nov 2009 17:13:04 -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 nAONkLaF005024; Tue, 24 Nov 2009 17:46:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAONkKre005023; Tue, 24 Nov 2009 17:46:20 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 24 Nov 2009 17:46:20 -0600 From: Nicolas Williams To: Kyle Hamilton Message-ID: <20091124234620.GA773@Sun.COM> References: <6b9359640911241414o1468616ajfdd0840f84e2cbc7@mail.gmail.com> <4B0C6444.2030500@extendedsubset.com> <6b9359640911241539n6fecc68dlbb3eab96b10461ba@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b9359640911241539n6fecc68dlbb3eab96b10461ba@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on the protocol and backward-compatibility (was: Server-only solution - proposed text) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:13:15 -0000 On Tue, Nov 24, 2009 at 03:39:38PM -0800, Kyle Hamilton wrote: > I'm aware that my proposal doesn't offer complete protection from an > MITM. What it does provide is protection that the MITM can't see > what's there. That's insufficient. From Nicolas.Williams@sun.com Tue Nov 24 16:14:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F243A67F7 for ; Tue, 24 Nov 2009 16:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.221, 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 swhmwwlDPNJO for ; Tue, 24 Nov 2009 16:14:39 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 354A13A6825 for ; Tue, 24 Nov 2009 16:14:39 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAP0EQGw002633 for ; Wed, 25 Nov 2009 00:14:26 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 nAP0EQ09005077 for ; Tue, 24 Nov 2009 17:14: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 nAONtG1A005031; Tue, 24 Nov 2009 17:55:16 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAONtGFK005030; Tue, 24 Nov 2009 17:55:16 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 24 Nov 2009 17:55:16 -0600 From: Nicolas Williams To: Kyle Hamilton Message-ID: <20091124235516.GB773@Sun.COM> References: <6b9359640911241522q6e31633bp3fd48bc2922c0cdf@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b9359640911241522q6e31633bp3fd48bc2922c0cdf@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:14:40 -0000 On Tue, Nov 24, 2009 at 03:22:57PM -0800, Kyle Hamilton wrote: > This is absolutely essential. TLS extensions exist, but SSL 3 is > still commonly used. There's no reason why SSL 3 shouldn't benefit > from anything that happens after-the-fact, even though it was never an > actual IETF protocol. There is no fixing re-negotiation without protocol changes. As far as SSLv3 goes the only real issue is: how hard are protocol changes to implement? (And that's assuming that there are SSLv3 implementors who will bother patching, as opposed to telling their customers to just upgrade.) > The only issue I see is... we've got an issue in signalling back to > the client that it knows how to do the updated handshake. Would a > slightly modified HelloRequest do it? For initial negotiations: - The C->S signal has to be a client hello extension. - The S->C signal can be either or both of a server hello extension and/or a server Finished message verify_data computation change. (Note that either way you can fallback on unsafe behavior, if you like.) We do need signalling in both directions during the initial negotiations. For re-negotiations: - No signal is needed -- just modify the client and server Finished message verify_data computation to include a channel binding. - The RI proposal does this via hello extensions carrying parts of the channel binding, which indirectly gets them into the Finished message verify_data computation. The advantage to the RI approach is that if you have a TLS 1.1+ stack then this change just fits the existing extensibility model that the stack was written for. The disadvantages to the RI approach are: it doesn't fit as well for pre-TLS 1.1 implementations, and, more importantly, it requires that the peers check the hello extension data sent. Whereas just adding the data to the verify_data computation without actually sending doesn't require any such checking. Nico -- From mrex@sap.com Tue Nov 24 16:21:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13873A67BD for ; Tue, 24 Nov 2009 16:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 7lMzhUidT8gN for ; Tue, 24 Nov 2009 16:21:09 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 762033A6825 for ; Tue, 24 Nov 2009 16:21:09 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAP0KrHQ015601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 01:20:53 +0100 (MET) From: Martin Rex Message-Id: <200911250020.nAP0KqO1013495@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Wed, 25 Nov 2009 01:20:52 +0100 (MET) In-Reply-To: <6b9359640911241414o1468616ajfdd0840f84e2cbc7@mail.gmail.com> from "Kyle Hamilton" at Nov 24, 9 02:14:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: yaronf@checkpoint.com, tls@ietf.org Subject: Re: [TLS] Thoughts on the protocol and backward-compatibility (was: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:21:10 -0000 > > Thus, I support the idea of using a new magic value in the cipher list > to indicate that a client has been patched (with the patch including > "must not negotiate this cipher suite, but including it means that the > server knows that the client can do the new renegotiation semantics"). > I also support the idea of standards action with all due haste (once > things are agreed upon) to update TLS 1.0, 1.1, and 1.2 with new > semantics (and the Standards Action necessary to allocate a new cipher > suite tag), with a recommendation to also update SSL 3.0 > implementations. (SSL 2 is just bad in the first place, and I see no > reason to try to improve it.) To me it looks like there is a serious problem with the current approach of the magic cipher suite in TLS extension RI. If you have an SSLv3 or TLS client with not fallback, then the most common conservative approach for the widest interop is to _NOT_ use TLS extensions. So if that client sends only the magic cipher suite but the server doesn't signal back -- you have a problem if the server wants to use renegotiation. If the server asks for renegotiation then the client, not knowing about the servers status will conservatively assume this is an old server. What should it send on the renegotiate request? If it sends only the magic cipher suite in the renegotiation ClientHello? Then TLS extension RI requires the server to abort. Send a ClientHello without the magic ciphersuite? Then the server will assume it is an attack and abort. So what is the best thing for a conservative client to do? Not to upgrade! Keep it like it is and require the server to allow renegotiation for backwards interop if the server really needs it. The other solution is that the server operator reorganizes his server so that he doesn't need renegotiation any more. In most scenarios, renegotiation is a feature needed by the server, not by the client. If there was a fix for the renegotiation problem that worked for all usage scenarios and protocol versions, then I would risk adding that to our TLS implementation. But we don't use renegotiation, we only have it in the client because some sites needed it. I'm not going to risk shipping a patch that suddenly starts sending TLS extensions in the ClientHello. Our client has never done that, and therefore we never needed fallbacks. I would wait at least several month before thinking about a change to the client with such a disruptive potential, and let the others find out the problems. Impairing the interoperability of a large amount of clients in order to fix a problem of a small number of servers seems questionable to me. -Martin From marsh@extendedsubset.com Tue Nov 24 16:24:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8B63A6877 for ; Tue, 24 Nov 2009 16:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 Qx0IRUK4dfYm for ; Tue, 24 Nov 2009 16:24:18 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 2381A3A67DF for ; Tue, 24 Nov 2009 16:24:18 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1ND5g4-000EnD-ID; Wed, 25 Nov 2009 00:24:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7500D603A; Wed, 25 Nov 2009 00:24:11 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1990cZfiE18gs0aHbVgW8IFJp9FINh4EKg= Message-ID: <4B0C792B.1080504@extendedsubset.com> Date: Tue, 24 Nov 2009 18:24:11 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kyle Hamilton References: <6b9359640911241414o1468616ajfdd0840f84e2cbc7@mail.gmail.com> <4B0C6444.2030500@extendedsubset.com> <6b9359640911241539n6fecc68dlbb3eab96b10461ba@mail.gmail.com> In-Reply-To: <6b9359640911241539n6fecc68dlbb3eab96b10461ba@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on the protocol and backward-compatibility (was: Server-only solution - proposed text) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:24:19 -0000 Kyle Hamilton wrote: > I'm aware that my proposal doesn't offer complete protection from an > MITM. What it does provide is protection that the MITM can't see > what's there. No server-only fix can provide meaningful secrecy for the client certificate. It's the client that possesses the client cert that you want to protect, right? Changes have to be made there, in addition to the server. Will you still support servers which request the client cert on the initial handshake? If so, all MitM has to do is to imitate the server long enough to ask the client for his cert! Sure, he may not be able to forge the Finished verify_data, but he doesn't have to. The client is required by the protocol to transmit the cert, that's all there is to it. If you don't care about clients supporting existing servers (admins are scrambling to disable renegotiation as we speak) then you can make a somewhat disruptive change so that clients can require to strongly auth the servers before a server-initiated renegotiation asks them to supply the cert. Nothing stops you from writing such a client app today, it requires no changes to the TLS spec. But this could have been done years ago by web browsers if they had wanted to, but for whatever reason (most) https client apps seem to treat the client cert handling as an afterthought. I, too, think renegotiation is useful and worth saving. But it will take additional restrictions (at higher layers, not TLS) if you want clients to be able to make their certs secret. - Marsh From mrex@sap.com Tue Nov 24 16:34:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3950E3A6857 for ; Tue, 24 Nov 2009 16:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 EE1bZKpAPRcF for ; Tue, 24 Nov 2009 16:34:28 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2A1AB3A67BD for ; Tue, 24 Nov 2009 16:34:27 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAP0YLFg014903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 01:34:21 +0100 (MET) From: Martin Rex Message-Id: <200911250034.nAP0YLIQ014338@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Wed, 25 Nov 2009 01:34:21 +0100 (MET) In-Reply-To: <6b9359640911241522q6e31633bp3fd48bc2922c0cdf@mail.gmail.com> from "Kyle Hamilton" at Nov 24, 9 03:22:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:34:29 -0000 Kyle Hamilton wrote: > > 4.3.1: > Clients which choose to fall back to an extensionless mode of > operation MUST include the magic cipher suite [TBD] in any such > handshake. Servers MUST reject any ClientHello which uses this > cipher suite but does not include RI with a fatal "handshake_failure" > alert. Because servers ordinarily ignore unknown cipher suites, this > cipher suite can be added safely on any handshake, thus allowing > detection and prevention of the MITM attack described above. > > This is absolutely essential. TLS extensions exist, but SSL 3 is > still commonly used. There's no reason why SSL 3 shouldn't benefit > from anything that happens after-the-fact, even though it was never an > actual IETF protocol. > > The only issue I see is... we've got an issue in signalling back to > the client that it knows how to do the updated handshake. Would a > slightly modified HelloRequest do it? Aha. Someone noticed that the S->C signaling is missing. I suggest using a bit in ServerHello.server_version. So far, the magic cipher suite idea in TLS extension RI is a "solution" to the downgrade vulnerability from the automatic reconnect fallback in TLS clients. So as far as SSLv3 support is concern, TLS extension RI is still firmly determined to exterminate SSLv3 and with the magic cipher suite, it'll kill conservative TLS clients along with it. -Martin From mrex@sap.com Tue Nov 24 17:21:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E271428C0F9 for ; Tue, 24 Nov 2009 17:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 931pPd0mgqv2 for ; Tue, 24 Nov 2009 17:21:20 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D1A3B28C115 for ; Tue, 24 Nov 2009 17:21:19 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAP1LDqu020157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Nov 2009 02:21:13 +0100 (MET) From: Martin Rex Message-Id: <200911250121.nAP1LD3J017142@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 25 Nov 2009 02:21:13 +0100 (MET) In-Reply-To: <4B0BE902.6070803@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Nov 24, 9 02:09:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Subject: [TLS] compression_method instead of server_version ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 01:21:21 -0000 Dear TLS WG, Dr Stephen Henson wrote: > > Could use one bit of the compression_method field in ServerHello. Since there > are only two actually defined since it first appeared in SSLv3 I don't think > we'll run out any time soon. I would like to get an idea about the acceptability of using ServerHello.compression_method for S->C signaling instead of the ServerHello.server_version that I currently use in my proposal. Since the value range of compression methods is partitioned, shaving a single bit is IMHO not an option. We would have to get a single compression_method assigned, and then relocate the real "common compression_method" that the server selected to a different location -- Server.Random. There seems to be an issue with some hardware/chips that may have an issue with TLS version changing (and its happened before with TLSv1.1...) Sending a personal reply to me rather to the list with just "no problem" or "rather not" would be sufficient. -Martin From djhopwood@googlemail.com Tue Nov 24 17:23:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E929E3A63D3 for ; Tue, 24 Nov 2009 17:23:43 -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 qANAZDh6S-8I for ; Tue, 24 Nov 2009 17:23:43 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 0599F3A67C1 for ; Tue, 24 Nov 2009 17:23:41 -0800 (PST) Received: by ewy7 with SMTP id 7so174613ewy.28 for ; Tue, 24 Nov 2009 17:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=WepTSyqXHfojiRPA1zsFOTFn63+hPdYimvfG2gvXxkM=; b=D1ZrxMFykGLQcO19PdKhWAYGaGOzVQo/VDDu/SjFVVSnfiKA0yOlQ5/8NQewIw/IHx Ibc+HAf0A3H2y8AHq7Kx6cRiOd66cG2LUM85MZmLJilewLAjJZ0KZl8ujAbENsXUqdJu 4wSta7ewd8djog6oMUteRceRZPGJQeD0MTR9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=wblEtCWJGfDlylwEx1Znic/TRD++a3NEDHWNQQUxDysCfE+ZtNevHWeP3YDhnwEMeN SSUpzTvLuHneQwsWePRI+MItvFcCLEqER2zwzOhHF3eElQDRN1+p/HSnq0p8IoMwlsja 2Y62ppF5np/qaGf9CoLrFqXHvCOhElxfyHMEw= Received: by 10.213.0.216 with SMTP id 24mr5960988ebc.10.1259112213502; Tue, 24 Nov 2009 17:23:33 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 13sm609209ewy.9.2009.11.24.17.23.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 17:23:29 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0C870E.3060600@jacaranda.org> Date: Wed, 25 Nov 2009 01:23:26 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> <87aayci2wn.fsf@mocca.josefsson.org> In-Reply-To: <87aayci2wn.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9F7AB2623F0DE35413D0196E" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 01:23:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9F7AB2623F0DE35413D0196E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simon Josefsson wrote: > Yoav Nir writes: >=20 >> Hi Martin. >> >> I see that you use the protocol field for the S->C signaling, but at l= east it's on the ServerHello rather than the handshake record header. >> >> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect pr= otocols. A server answering with the wrong SSL version may just be "weird= " enough for the middlebox to drop the connection. I'm not at that side o= f Check Point, but I know that much of the protection code is not targete= d at a particular attack, but just performs a sanity check on the protoco= ls. >=20 > Presumably RI has the same concern: a deep-packet inspector may check > for "unknown" extensions (similar to checking for "unknown" TLS > versions) and reject the connection. If it does then it's nonconformant to TLS. (In general, protocol specifications impose requirements on any non-transparent middlebox, just as they do on the endpoints.) A middlebox that rejected an unexpected protocol version (i.e. one that is inconsistent with the record version in later messages), OTOH, would not be nonconformant to TLS, or at least that case is certainly not as clear-cut. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig9F7AB2623F0DE35413D0196E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksMhxQACgkQWUc8YzyzqAdikQD/eJK5jEQG5jyY2j0r9YxRo0uU VcXDu6gq0L9SvXBbbgQA/jOkoFJL8KtSoF8aYmz/08cIPqnOhirRFfSkKaq0D3F2 =OA/M -----END PGP SIGNATURE----- --------------enig9F7AB2623F0DE35413D0196E-- From djhopwood@googlemail.com Tue Nov 24 17:27:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA2428C144 for ; Tue, 24 Nov 2009 17:27:49 -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 RlaAzu627R1R for ; Tue, 24 Nov 2009 17:27:48 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 367DF3A6828 for ; Tue, 24 Nov 2009 17:27:48 -0800 (PST) Received: by ewy7 with SMTP id 7so177776ewy.28 for ; Tue, 24 Nov 2009 17:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Z/xt7ErRKVLjrU+GRQiUDz6UxsOOTolXJwymWcXgAbY=; b=ZNK3j6WpaES9pwAHwV/J0fZrD+km9Cp1VajYhN6i+1/QQiSsl/8rsJOCfokIkRRJ7V F+DJC+mzEucXRNDgNQI8uTosLs3ptqQT+u5ikegQU/hwLYXkJIODpw1du38OJUBV8DkR D8/RxV+nGfpbCJmzRopEkNQK0WA7rVKZHTqq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Bv8QLBLXGNSZ9lizYMfYysIHAbqi1E/7RYvI8dfn8lX6AK5OZO1MAKV6g8x0t8dXZ9 UhL6wugikXBTyqCpbFuk/21KjB+fR1Kx1T9rxnBR/41rG657DOXrDeqyi8ee6tfDTBK/ 8AG+hhzF6TeAxaQy/81NAovsWDSxapqFEvhyE= Received: by 10.213.23.210 with SMTP id s18mr7123889ebb.89.1259112448152; Tue, 24 Nov 2009 17:27:28 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm573390ewy.0.2009.11.24.17.27.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 17:27:27 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0C8802.6040807@jacaranda.org> Date: Wed, 25 Nov 2009 01:27:30 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> <87aayci2wn.fsf@mocca.josefsson.org> <23ACBC75-62CC-4521-8BB5-A3D425C07204@checkpoint.com> <876390glba.fsf@mocca.josefsson.org> In-Reply-To: <876390glba.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD0B74E50E77C24A3AC33294F" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 01:27:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0B74E50E77C24A3AC33294F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simon Josefsson wrote: > Yoav Nir writes: [...] >> I've said several times that I prefer Martin's approach. It's just >> that I'd prefer a more subtle way for the S->C signalling (like >> something in the random or GMT) >=20 > Here is another idea: use one bit of the ciphersuite space. So if the > server would have selected TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA =3D { > 0x00,0x13 } if the server would support the renegotiation protocol it > would return { 0x70, 0x13 } or { 0x00, 0x13 | 0x70 } or similar instead= =2E That's even more likely to upset an IDS, since it has a legitimate reason= to kill connections that it sees as using a ciphersuite that is not on a list of known-secure ciphersuites. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigD0B74E50E77C24A3AC33294F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksMiAMACgkQWUc8YzyzqAdXCwD/XyzfOgD9oTracQAYIoP1nXeY 3kX2env8MrXTnk8+1F0A/j/0su0S/erBf3iNHhKkyIGGFRb4KzErzVmeGYjIwUPN =qa7E -----END PGP SIGNATURE----- --------------enigD0B74E50E77C24A3AC33294F-- From djhopwood@googlemail.com Tue Nov 24 17:29:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FB63A6778 for ; Tue, 24 Nov 2009 17:29:49 -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 nid4KkNpQAVM for ; Tue, 24 Nov 2009 17:29:49 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id D42AA28C0ED for ; Tue, 24 Nov 2009 17:29:48 -0800 (PST) Received: by ewy7 with SMTP id 7so179167ewy.28 for ; Tue, 24 Nov 2009 17:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Y65YGZ8VC2nl9oo4vfC8gsXV9iclluWBhRRay7zxZtw=; b=oHpAnNDnC4x4ITyoihS6HHbgg6SaoaDOdBAV8Pnm5xSmVQIre5NyP9dZLcW50aEf1P 2jCNQg0Gb+72+BUsDrkT57LLCS5zyr9dhJHlX+Pqs96bzRetKk3vjwnM6iFgtgqrJI1v iPLi5Siln+MKuHmAWsRWLV8sFAuphoi16t7UI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=be+YTvA7uj35FWXYOXxClCyhIcLkViq3MHWbB/Hf5ksAprLa4kA/aqyTZvIvYF8cDA 8OyR3QGfkm7yImQKfEk3SkPedC8FSXKnSJw9l2YV6RcC+oychEFuSZBezQQrhD3YOc5I wIfKfqG35cD5+7zkacGPHRugyxnMb0765BTzE= Received: by 10.213.3.140 with SMTP id 12mr5942349ebn.20.1259112580797; Tue, 24 Nov 2009 17:29:40 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm583109ewy.12.2009.11.24.17.29.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 17:29:40 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0C8887.9070906@jacaranda.org> Date: Wed, 25 Nov 2009 01:29:43 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: from "YoavNir" at Nov 24, 9 10:42:12 am <200911241634.nAOGYsEt009318@fs4113.wdf.sap.corp> <7E1DF37F1F42AB4E877E492C308E6AC40278B7D4@XCH57YKF.rim.net> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC40278B7D4@XCH57YKF.rim.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB7255AEE8ADBE68075793460" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 01:29:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7255AEE8ADBE68075793460 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rob P Williams wrote: > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Martin Rex >> If those firewalls are concerned about security, they should >> be adding filters for traditional renegotiation--and when >> doing that, they could fix such obvious flaws on the way. >=20 > I hope those firewalls cannot read our encrypted renegotiation taking > place to filter it. They can detect a renegotiation because the handshake message types are not encrypted. (Yes, that's arguably a design flaw.) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB7255AEE8ADBE68075793460 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksMiIcACgkQWUc8YzyzqAeKQwD/TK123BozPOr5GfQ3cekV32aR VZkmmoJZTCG5vpr4IaoA/i750LDbwdpuCA/Kvfrsa5Tzwq+hz+6Vp2kkNGuYtoWP =t4L4 -----END PGP SIGNATURE----- --------------enigB7255AEE8ADBE68075793460-- From mrex@sap.com Tue Nov 24 18:07:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4EFF28C161 for ; Tue, 24 Nov 2009 18:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 nXRpHl3QZvEM for ; Tue, 24 Nov 2009 18:07:14 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id AAE6C28C160 for ; Tue, 24 Nov 2009 18:07:13 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAP276jo001917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 03:07:06 +0100 (MET) From: Martin Rex Message-Id: <200911250207.nAP275Z6019896@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 25 Nov 2009 03:07:05 +0100 (MET) In-Reply-To: <200911201853.nAKIrF53018260@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 20, 9 07:53:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 02:07:14 -0000 Martin Rex wrote: > > Dr Stephen Henson wrote: > > > > ServerHello contains the MAGIC value in the CipherSuite indicator: > > we know this can never happen by accident. The real ciphersuite > > indicator is placed elsewhere, e.g. part of session ID. > > Session ID definition slightly modified to permit 34 bytes > > instead of 32. > > Signaling through ciphersuite ID in ServerHello should work. > Middle Boxes may still be confused. > > But I would definitely _NOT_ touch the session ID, in particular > not make it longer. Although I do not like the abuse the ciphersuite ID for S->C, that doesn't mean that I could not be convinced to use it. Reasons why I do not like it: - currently at least some servers assign the session ID consciously, to help them in their session cache management, maybe even loadbalancing, or just to make it collision-safe. I wouldn't like to force them to repartition the 32-bytes - AFAIK there are loadbalancers out there (NAT-type) that can use the SSL session ID to balance (without opening/terminating SSL in a reverse-proxy fashion. They might have a problem when the session ID returned from the server is > 32 bytes and does not match the session ID that the client sends in the ClientHello of parallel connection. -Martin From marsh@extendedsubset.com Tue Nov 24 18:14:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CB03A6952 for ; Tue, 24 Nov 2009 18:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 vfFCR+oI9sef for ; Tue, 24 Nov 2009 18:14:26 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 23FEA3A68BC for ; Tue, 24 Nov 2009 18:14:26 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1ND7Of-000Jeg-7z; Wed, 25 Nov 2009 02:14:21 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3EBE9603A; Wed, 25 Nov 2009 02:14:19 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/4m5lTyZsgjLMaBdBYaA+aHVE8PlTrWhw= Message-ID: <4B0C92FA.1070906@extendedsubset.com> Date: Tue, 24 Nov 2009 20:14:18 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911250207.nAP275Z6019896@fs4113.wdf.sap.corp> In-Reply-To: <200911250207.nAP275Z6019896@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Need for S->C signaling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 02:14:27 -0000 Martin Rex wrote: > Although I do not like the abuse the ciphersuite ID for S->C, > that doesn't mean that I could not be convinced to use it. > > Reasons why I do not like it: > > - currently at least some servers assign the session ID > consciously > I wouldn't like to force them to repartition the 32-bytes Yes, that could force a major application change so it's off the table. > They might have a problem when the session ID returned from > the server is > 32 bytes and does If we're going to increase the max size of the Server Hello structure, we might as well define a new field. Or just use an extension. Seriously, is it that big a deal to use an extension in the SERVER Hello, if it's use was negotiated in the Client Hello? - Marsh From djhopwood@googlemail.com Tue Nov 24 20:17:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0173A67DA for ; Tue, 24 Nov 2009 20:17:11 -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 HvNyfehKIZRC for ; Tue, 24 Nov 2009 20:17:10 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 42F443A6951 for ; Tue, 24 Nov 2009 20:17:10 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so610738eyf.51 for ; Tue, 24 Nov 2009 20:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=nWnhc0952dgH2bHdT7A/J9liX6KtsLyTvxNNVqTzmY8=; b=h+Ax5Biem7FakJl42fYkDXUuXaVAl1JamhalF+g5NkB2mWyMH1qMm1khTb5WjMz0u/ GX4XHaJI4gmhUYX5h/dZtw5P55NwCpgV8Txsc1RvC9QVpzvcqbeD9wXcRpXlMrshfwDQ 2JOXQC/7P/UxbRVNSmZeMLTkrNRhgMZlj3frg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=sEY5m9uY26VfTgltiydfCuXhC8Hv32khMA2it26oQB8CgPPxrfYj4d5J7o2v5VoMkP hQSl+nd4zbwzKVvzOPhddlP0vmdsA2EacCS2Nld9p9Q29CPna0Qpqqecsvv5fS583ha/ ETVXxVA2ARNWc/FyhdFo4zk0xf2vuMTjhlLrw= Received: by 10.213.0.218 with SMTP id 26mr7090932ebc.85.1259122622434; Tue, 24 Nov 2009 20:17:02 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm699122ewy.4.2009.11.24.20.17.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 20:17:01 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0CAFAC.8040003@jacaranda.org> Date: Wed, 25 Nov 2009 04:16:44 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911250136.nAP1aNtS018080@fs4113.wdf.sap.corp> In-Reply-To: <200911250136.nAP1aNtS018080@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB74E2677E6A8A0AF91ED44AA" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 04:17:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB74E2677E6A8A0AF91ED44AA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > David-Sarah Hopwood wrote: >>> I hope those firewalls cannot read our encrypted renegotiation taking= >>> place to filter it. >> >> They can detect a renegotiation because the handshake message types >> are not encrypted. >=20 > ContentTypes are visible in the cleartext part of the record protocol. >=20 > Handshake message types (HandshakeType, RFC5246 7.4) are not. I stand corrected. I should have said that Firewalls, etc. can detect a renegotiation because ContentTypes are not encrypted. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB74E2677E6A8A0AF91ED44AA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksMr78ACgkQWUc8YzyzqAf1DQD+IV0+c6FBOd9gNXiQ5YniJ0WX l4ass/Q+TqAjbHLBep4A/jX7whEn6uiJD8AsrfceW3moSZjBEUkauD+NdK8Dbl30 =A974 -----END PGP SIGNATURE----- --------------enigB74E2677E6A8A0AF91ED44AA-- From pgut001@wintermute01.cs.auckland.ac.nz Tue Nov 24 21:41:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8AA28C1DC for ; Tue, 24 Nov 2009 21:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.412 X-Spam-Level: X-Spam-Status: No, score=-5.412 tagged_above=-999 required=5 tests=[AWL=1.187, 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 wRF9I-Ti9Tct for ; Tue, 24 Nov 2009 21:41:39 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 1EAB928C1B1 for ; Tue, 24 Nov 2009 21:41:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 168A24142CC; Wed, 25 Nov 2009 18:41:28 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH4cfmWmn7pf; Wed, 25 Nov 2009 18:41:27 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C3CD64142C8; Wed, 25 Nov 2009 18:41:27 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NDAd5-0000X6-H2; Wed, 25 Nov 2009 18:41:27 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NDAd5-00017P-5c; Wed, 25 Nov 2009 18:41:27 +1300 From: Peter Gutmann To: stefan@aaa-sec.com, tls@ietf.org In-Reply-To: Message-Id: Sender: pgut001 Date: Wed, 25 Nov 2009 18:41:27 +1300 Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 05:41:40 -0000 Stefan Santesson writes: >1. Return an RI extension, even if one was not sent by the client. The >problem is that this is a violation of the TLS protocol. It is illegal to add >a server extension that was not present in the client hello. But except that >problem, it might work. This shouldn't be so bad, the client has already indicated via the magic cipher suite that it'll know how to deal with this, so it shouldn't break anything. >3. Define a new handshake message that is sent right after ServerHello. This >handshake message would be sent back to the client only of the magic >CipherSuite was sent by the client, confirming that the server supports >updated finished messages. I=B9m not sure whether this would cause any >serious problems, but in case it doesn=B9t, this is the one I like best. It should be OK for the same reason that the RI extension is, but I don't know if it's worth defining a new message type just for this, an RI ext might be less overhead to implement. It really depends on how many implementations support extensions already... Peter. From djhopwood@googlemail.com Tue Nov 24 21:55:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17AE63A6927 for ; Tue, 24 Nov 2009 21:55:40 -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 WRn-saAT-BA9 for ; Tue, 24 Nov 2009 21:55:38 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 87B693A679F for ; Tue, 24 Nov 2009 21:55:38 -0800 (PST) Received: by ewy6 with SMTP id 6so4036258ewy.29 for ; Tue, 24 Nov 2009 21:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=dn2GU7XUANdqT8ON9u7l14ZSRDEPCtOGIQn/i1UBAOk=; b=whBBHyf8VQhAEBCt6LFA7H6GBSfHIkoz3fqFaV+udZsvNOOpF23Eo1G/0jxZ5uag90 0QCLoTRO8fO+6S/7bLXic/4bIL/q+6j5oS4fTGAugi49wBR+FOS7aQu4iyEwXutoxXMZ K5PGlEGcDBa2kxaaOLFOVkzuiXlvInUGme07I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=D5Duy/O4wN1YusbTVbeWpnFNdH/24obbkgpNmF6FSYvzJgD3IHT+gIo6YCW/u26PSt YQmFERBfeu1QtWgrZ4AdUmihS1Qr6FxMn7LxZsIsybu5Bhk89imotp9aGAmF39guyeGg bLowlF9ga5Wob7Jt/bgUJxVeTxhN6vvHhA/74= Received: by 10.213.27.8 with SMTP id g8mr6153930ebc.58.1259128529499; Tue, 24 Nov 2009 21:55:29 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 16sm726302ewy.14.2009.11.24.21.55.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 21:55:27 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0CC6C9.5000606@jacaranda.org> Date: Wed, 25 Nov 2009 05:55:21 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B09ECAB.7050205@bolyard.me> <200911230306.nAN365xl020466@fs4113.wdf.sap.corp> <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> In-Reply-To: <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig0ACE7E29E3ADDB64822A95DA" Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 05:55:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0ACE7E29E3ADDB64822A95DA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ben Laurie wrote: > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: >> It is the golden rule of the IETF >> "be liberal in what you accept, be conservative in what you send out" >=20 > That has proved to be a less-than-great idea, particularly in > protocols where you care about security, which is to say, all of them. =2E.. and if anyone is not convinced yet that the "be liberal" part is actually a *bad* idea, then read . --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig0ACE7E29E3ADDB64822A95DA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksMxtAACgkQWUc8YzyzqAdt2AD6A2jqtGxMeu0q4+RdPxJt6zt8 /iEGfVGATD1z7AOeRCsA+gM5Q/zzapXTVtIa4ijNEZDbT8KF4T55V9io5MpcafRK =kA4j -----END PGP SIGNATURE----- --------------enig0ACE7E29E3ADDB64822A95DA-- From stefan@aaa-sec.com Wed Nov 25 00:11:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7288F3A67F0 for ; Wed, 25 Nov 2009 00:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XUns7Og7m5L for ; Wed, 25 Nov 2009 00:11:40 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 67D4E3A677D for ; Wed, 25 Nov 2009 00:11:39 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D16B128E286 for ; Wed, 25 Nov 2009 09:11:35 +0100 (CET) Received: (qmail 88931 invoked from network); 25 Nov 2009 08:11:33 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Nov 2009 08:11:33 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 09:11:32 +0100 From: Stefan Santesson To: Peter Gutmann , Message-ID: Thread-Topic: [TLS] Other S->C signaling methods Thread-Index: AcptpuW/RyhsUhaRKkiYdrM6M3/UkA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:11:41 -0000 So how would this work as a middle way between the proposals: C->S Signaling: 1) Client MUST include either the magic CipherSuite or RI extension or both 2a) TLS compatible server MUST support magic CipherSuite and RI. 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI S->C Signaling: 1) Servers MUST include RI Finished calculation: 1a) The RI of the serverHello holds necessary data from previous handshake; or 1b) Finished calculation is modified to include virtual handshake messages This would allow the current implementation of RI (more or less) but also allow safe fallback when connecting to servers that can't parse extensions. All servers must include the bits of an RI extension in the server Hello, but that should be a lot easier than to implement full extension handling for receiving RI from the client. This would at least save us the ugliest hacks when it comes to S->C signaling. /Stefan On 09-11-25 6:41 AM, "Peter Gutmann" wrote: > Stefan Santesson writes: > >> 1. Return an RI extension, even if one was not sent by the client. The >> problem is that this is a violation of the TLS protocol. It is illegal to add >> a server extension that was not present in the client hello. But except that >> problem, it might work. > > This shouldn't be so bad, the client has already indicated via the magic > cipher suite that it'll know how to deal with this, so it shouldn't break > anything. > >> 3. Define a new handshake message that is sent right after ServerHello. This >> handshake message would be sent back to the client only of the magic >> CipherSuite was sent by the client, confirming that the server supports >> updated finished messages. I=B9m not sure whether this would cause any >> serious problems, but in case it doesn=B9t, this is the one I like best. > > It should be OK for the same reason that the RI extension is, but I don't know > if it's worth defining a new message type just for this, an RI ext might be > less overhead to implement. It really depends on how many implementations > support extensions already... > > Peter. From simon@josefsson.org Wed Nov 25 00:14:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CCD3A68E8 for ; Wed, 25 Nov 2009 00:14:14 -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 S1LnHNVXGsSG for ; Wed, 25 Nov 2009 00:14:13 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 669743A67F0 for ; Wed, 25 Nov 2009 00:14:13 -0800 (PST) Received: from mocca.josefsson.org (94.191.147.57.bredband.tre.se [94.191.147.57]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAP8DxZt018768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Nov 2009 09:14:05 +0100 From: Simon Josefsson To: David-Sarah Hopwood References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> <87aayci2wn.fsf@mocca.josefsson.org> <4B0C870E.3060600@jacaranda.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091125:david-sarah@jacaranda.org::wnHMvqZn9VibgNZC:37CL X-Hashcash: 1:22:091125:tls@ietf.org::KLCvI5JrgIe2E5C3:Ow74 Date: Wed, 25 Nov 2009 09:13:56 +0100 In-Reply-To: <4B0C870E.3060600@jacaranda.org> (David-Sarah Hopwood's message of "Wed, 25 Nov 2009 01:23:26 +0000") Message-ID: <87pr77c98b.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:14:15 -0000 David-Sarah Hopwood writes: > Simon Josefsson wrote: >> Yoav Nir writes: >> >>> Hi Martin. >>> >>> I see that you use the protocol field for the S->C signaling, but at least it's on the ServerHello rather than the handshake record header. >>> >>> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protocols. A server answering with the wrong SSL version may just be "weird" enough for the middlebox to drop the connection. I'm not at that side of Check Point, but I know that much of the protection code is not targeted at a particular attack, but just performs a sanity check on the protocols. >> >> Presumably RI has the same concern: a deep-packet inspector may check >> for "unknown" extensions (similar to checking for "unknown" TLS >> versions) and reject the connection. > > If it does then it's nonconformant to TLS. Well, TLS extensions are not conformant to SSLv3 either. Even for TLS, it doesn't seem unreasonable to assume that if some middlebox reject unknown server versions it may just as well reject unknown TLS extensions, on the basis of "don't allow what we don't know about". I remain unconvinced that this is an important issue though. /Simon From ynir@checkpoint.com Wed Nov 25 00:36:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B463A6989 for ; Wed, 25 Nov 2009 00:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Mdx8Kfy9LSLZ for ; Wed, 25 Nov 2009 00:36:19 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4760F3A67B0 for ; Wed, 25 Nov 2009 00:36:19 -0800 (PST) X-CheckPoint: {4B0CE8C5-3-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 49FB129C011; Wed, 25 Nov 2009 10:36:14 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 28B0C29C005; Wed, 25 Nov 2009 10:36:14 +0200 (IST) X-CheckPoint: {4B0CE8C5-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAP8aDGo002127; Wed, 25 Nov 2009 10:36:13 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 25 Nov 2009 10:36:19 +0200 From: Yoav Nir To: Dr Stephen Henson Date: Wed, 25 Nov 2009 10:36:10 +0200 Thread-Topic: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted Thread-Index: AcptqlvDLYLqR8TpQEePPQ5SQ3LyaA== Message-ID: <83159A1E-F3A9-4EA7-A398-A3B30670DAB3@checkpoint.com> References: <200911231557.nANFvIbZ006751@fs4113.wdf.sap.corp> <87aayci2wn.fsf@mocca.josefsson.org> <23ACBC75-62CC-4521-8BB5-A3D425C07204@checkpoint.com> <876390glba.fsf@mocca.josefsson.org> <4B0BE902.6070803@drh-consultancy.demon.co.uk> In-Reply-To: <4B0BE902.6070803@drh-consultancy.demon.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:36:20 -0000 On Nov 24, 2009, at 4:09 PM, Dr Stephen Henson wrote: > Simon Josefsson wrote: >> Yoav Nir writes: >>=20 >>> On Nov 24, 2009, at 1:21 PM, Simon Josefsson wrote: >>>=20 >>>> Yoav Nir writes: >>>>=20 >>>>> Hi Martin. >>>>>=20 >>>>> I see that you use the protocol field for the S->C signaling, but at = least it's on the ServerHello rather than the handshake record header. >>>>>=20 >>>>> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect p= rotocols. A server answering with the wrong SSL version may just be "weird"= enough for the middlebox to drop the connection. I'm not at that side of C= heck Point, but I know that much of the protection code is not targeted at = a particular attack, but just performs a sanity check on the protocols. >>>> Presumably RI has the same concern: a deep-packet inspector may check >>>> for "unknown" extensions (similar to checking for "unknown" TLS >>>> versions) and reject the connection. >>>>=20 >>>> I don't think this is a good argument to decide between the two >>>> proposals. IDSs will simply need to be upgraded to support one (or >>>> both) of the new proposals, and fortunately that is already required f= or >>>> other reasons, so it seems like a small concern to me. >>> I've said several times that I prefer Martin's approach. It's just >>> that I'd prefer a more subtle way for the S->C signalling (like >>> something in the random or GMT) >>=20 >> Here is another idea: use one bit of the ciphersuite space. So if the >> server would have selected TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA =3D { >> 0x00,0x13 } if the server would support the renegotiation protocol it >> would return { 0x70, 0x13 } or { 0x00, 0x13 | 0x70 } or similar instead. >>=20 >> It is an ugly solution, but I haven't seen it mentioned. >>=20 >=20 > Could use one bit of the compression_method field in ServerHello. Since t= here > are only two actually defined since it first appeared in SSLv3 I don't th= ink > we'll run out any time soon. Well, since we're adding information without increasing the size of the mes= sages, I guess it really is a compression method. From yangqinqin@huaweisymantec.com Wed Nov 25 00:45:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B963A6895 for ; Wed, 25 Nov 2009 00:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.399 X-Spam-Level: *** X-Spam-Status: No, score=3.399 tagged_above=-999 required=5 tests=[AWL=3.894, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYeCaVhCC59s for ; Wed, 25 Nov 2009 00:45:53 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 0CD853A686B for ; Wed, 25 Nov 2009 00:45:53 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=UTF-8 Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTN00L43PO1YLA0@hstga02-in.huaweisymantec.com> for TLS@ietf.org; Wed, 25 Nov 2009 16:45:38 +0800 (CST) Received: from y00144023 ([10.27.154.91]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KTN00G64PO1Y320@hstml02-in.huaweisymantec.com> for TLS@ietf.org; Wed, 25 Nov 2009 16:45:37 +0800 (CST) Message-id: <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> From: yangqinqin To: Marsh Ray References: <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com> Date: Wed, 25 Nov 2009 16:45:37 +0800 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:48:46 -0000 Marsh, Thank you for your reply. I have just joined the mailing list. In your draft, "If the other end attempts to authenticate with a different identity, the renegotiation MUST fail." How do you achieve it in the renegotiation? You also wrote in the draft, "For certificate based cipher suites, this means bitwise equality of the end-entity certificate. " This increases authentication steps. But original TLS renegotiation protocol has not this step. Thanks, Qinqin Yang ----- Original Message ----- From: Marsh Ray To: yangqinqin Cc: Steve Dispensa ; Nasko Oskov ; Eric Rescorla Sent: Wednesday, November 25, 2009 9:33 AM Subject: Re: some questions for your draft yangqinqin wrote: > Thank you for your reply. > But I have not joined the mailing list. And I didn' t find it in the > archives of the [TLS] mailing list. There are too many mails related to > this question. Moreover, english is not my native language. So I hope > you will give me answer. Here's one message I can find: http://www.ietf.org/mail-archive/web/tls/current/msg04136.html > I really don't like to allow both, change of identities during > renegotiation _and_ arbitrary interleaving of application data > with the renegotiation handshake messages. Applications > may get this wrong easily It sounds like the wording is motivated in part by the ambiguity of application data transmitted between the Change Cipher Spec and Finished messages. I suspect it's also a recognition that many applications are expecting authentication to strengthen across renegotiation, but not change entirely. - Marsh From ynir@checkpoint.com Wed Nov 25 01:39:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0618E3A6918 for ; Wed, 25 Nov 2009 01:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 NWUhkzt4p6TQ for ; Wed, 25 Nov 2009 01:39:39 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EB8AC3A684C for ; Wed, 25 Nov 2009 01:39:38 -0800 (PST) X-CheckPoint: {4B0CF79C-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6294229C013; Wed, 25 Nov 2009 11:39:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3BFE929C012; Wed, 25 Nov 2009 11:39:29 +0200 (IST) X-CheckPoint: {4B0CF798-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAP9bnGx023618; Wed, 25 Nov 2009 11:39:28 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 25 Nov 2009 11:39:26 +0200 From: Yoav Nir To: Stefan Santesson Date: Wed, 25 Nov 2009 11:39:18 +0200 Thread-Topic: [TLS] Other S->C signaling methods Thread-Index: Acptsy1zhxwZfDECTfuC9le7mA74Rg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 09:39:40 -0000 On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote: > So how would this work as a middle way between the proposals: >=20 > C->S Signaling: > 1) Client MUST include either the magic CipherSuite or RI extension or bo= th > 2a) TLS compatible server MUST support magic CipherSuite and RI. > 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI How about: 2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY suppor= t RI > S->C Signaling: > 1) Servers MUST include RI Since this violates the TLS specs, I think servers MUST include RI only if = the client included RI. Otherwise, they MUST use the tbd "other signal" > Finished calculation: > 1a) The RI of the serverHello holds necessary data from previous handshak= e; > or > 1b) Finished calculation is modified to include virtual handshake message= s >=20 >=20 > This would allow the current implementation of RI (more or less) but also > allow safe fallback when connecting to servers that can't parse extension= s. >=20 > All servers must include the bits of an RI extension in the server Hello, > but that should be a lot easier than to implement full extension handling > for receiving RI from the client. >=20 > This would at least save us the ugliest hacks when it comes to S->C > signaling. >=20 > /Stefan From stefan@aaa-sec.com Wed Nov 25 02:05:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9BE28C20D for ; Wed, 25 Nov 2009 02:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEJ17xeQJzyw for ; Wed, 25 Nov 2009 02:05:14 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 715E73A694F for ; Wed, 25 Nov 2009 02:05:14 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 779CF28FF9D for ; Wed, 25 Nov 2009 11:05:11 +0100 (CET) Received: (qmail 83710 invoked from network); 25 Nov 2009 10:05:08 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Nov 2009 10:05:08 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 11:05:05 +0100 From: Stefan Santesson To: Yoav Nir Message-ID: Thread-Topic: [TLS] Other S->C signaling methods Thread-Index: Acptsy1zhxwZfDECTfuC9le7mA74RgAA5Ur5 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 10:05:15 -0000 On 09-11-25 10:39 AM, "Yoav Nir" wrote: > > On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote: > >> So how would this work as a middle way between the proposals: >> >> C->S Signaling: >> 1) Client MUST include either the magic CipherSuite or RI extension or both >> 2a) TLS compatible server MUST support magic CipherSuite and RI. >> 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI > > How about: > 2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI > 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support > RI > Yes. That struck me as the right thing to do right after posting. >> S->C Signaling: >> 1) Servers MUST include RI > > Since this violates the TLS specs, I think servers MUST include RI only if the > client included RI. Otherwise, they MUST use the tbd "other signal" > Well, it would gracefully violate this rule of TLS. But it would be announced so it should not break anything... Or would it? It seems that we need to stretch something to make this work, and the question is what stretch is least ugly but still implementable. The big downside with abusing a bit of a current defined field (version or compression method) is: 1) Hopefully we will never have to do this type of fix again, but if we do, then what bit should we abuse next time around. 2) It obfuscates the protocol, makes it harder to understand and more likely to attract implementation errors in the future. /Stefan >> Finished calculation: >> 1a) The RI of the serverHello holds necessary data from previous handshake; >> or >> 1b) Finished calculation is modified to include virtual handshake messages >> >> >> This would allow the current implementation of RI (more or less) but also >> allow safe fallback when connecting to servers that can't parse extensions. >> >> All servers must include the bits of an RI extension in the server Hello, >> but that should be a lot easier than to implement full extension handling >> for receiving RI from the client. >> >> This would at least save us the ugliest hacks when it comes to S->C >> signaling. >> >> /Stefan > From Pasi.Eronen@nokia.com Wed Nov 25 04:53:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5265328C207 for ; Wed, 25 Nov 2009 04:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 aYhD455Rr-vo for ; Wed, 25 Nov 2009 04:53:52 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8B5303A6A2D for ; Wed, 25 Nov 2009 04:53:52 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPCr9iO020058; Wed, 25 Nov 2009 06:53:41 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:53:35 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:53:35 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 25 Nov 2009 13:53:15 +0100 From: To: , Date: Wed, 25 Nov 2009 13:53:14 +0100 Thread-Topic: [TLS] Other S->C signaling methods Thread-Index: Acptsy1zhxwZfDECTfuC9le7mA74RgAGs+gQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE51E@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 12:53:35.0347 (UTC) FILETIME=[4CD92430:01CA6DCE] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:53:53 -0000 Yoav Nir wrote: > > S->C Signaling: > > 1) Servers MUST include RI >=20 > Since this violates the TLS specs, I think servers MUST include RI > only if the client included RI. Otherwise, they MUST use the tbd > "other signal" The renegotiation-fix RFC will anyway have "Updates: RFC 5246" on the cover page, so it could (if the WG so chooses) relax this requirement in the current TLS specs. Best regards, Pasi From Pasi.Eronen@nokia.com Wed Nov 25 04:57:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFC528C103 for ; Wed, 25 Nov 2009 04:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 nb008sCroD2g for ; Wed, 25 Nov 2009 04:57:52 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 283F23A67B6 for ; Wed, 25 Nov 2009 04:57:52 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPCvfVo025046; Wed, 25 Nov 2009 06:57:46 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:57:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:57:20 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 25 Nov 2009 13:57:19 +0100 From: To: , Date: Wed, 25 Nov 2009 13:57:18 +0100 Thread-Topic: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: AcpsQPANqBomR3BsSUqPdx+FfSJvGABjWFyQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE525@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 12:57:20.0201 (UTC) FILETIME=[D2DF2390:01CA6DCE] X-Nokia-AV: Clean Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:57:53 -0000 Yngve Nysaeter Pettersen wrote: > I also think the finished document should include a timeline for > when lenient implementations should become strict, and refuse to > negotiate with unpatched peers. Without such a timeline I think it > will take much longer to get rid of unpatched implementations > (particularly servers) than is necessary to get this problem removed > from the net. IMO such a timeline should not be longer than 12 > months from the publication of the RFC. Leaving the decision for > such a sunset date to vendors is not a good idea (just look how long > SSLv2 and export ciphers were supported, mostly because a few major > internet services refused to upgrade). In general, vendors can choose to implement any RFC they want, or can choose not to do so. And users can choose to deploy some products, or can choose not to do so. Although it would be nice if we could just say "everyone SHOULD use TLS 1.2 (or IPv6, DNSSEC, ...) by end of 2010, and MUST switch off SSLv3 (or IPv4, NATs, unsigned DNS records, ..) by 2012, that's not something IETF documents usually say, because it wouldn't have much effect. (Or in other words: the incentives for doing or not doing something=20 for companies usually come from money, not RFC 2119 key words :-) Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Wed Nov 25 05:03:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45313A6A36 for ; Wed, 25 Nov 2009 05:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 6RRqdkadfFzU for ; Wed, 25 Nov 2009 05:03:27 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 02FBC3A6A24 for ; Wed, 25 Nov 2009 05:03:26 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPD302T029168; Wed, 25 Nov 2009 07:03:21 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:01:29 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:01:21 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 25 Nov 2009 14:01:20 +0100 From: To: Date: Wed, 25 Nov 2009 14:01:19 +0100 Thread-Topic: [TLS] simplistic renego protection Thread-Index: AcpseJJ3HutXpBvBQH69NX7w6B/aVQBVkzOQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE52B@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F310BB2AB@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 23, 9 12:19:03 pm <200911232007.nANK736K022320@fs4113.wdf.sap.corp> In-Reply-To: <200911232007.nANK736K022320@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 13:01:21.0335 (UTC) FILETIME=[62994470:01CA6DCF] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:03:27 -0000 Martin Rex wrote: > > Yes... and as Eric noted, as long as the 2nd handshake "directly > > follows" (=3Dno application data is exchanged using the first session), > > this seems to be secure already.... > > But you do realize that there is an attack scenario where the server > sees only an initial authentication, and the client sees a > renegotiation? Hmm... you're right, this could happen. But only if the client is OK with the server changing its certificate during renegotiation, and both certificates are accepted by the client. Having TLS endpoints change their certificates during renegotiation is highly likely to confuse many applications (and lead to security problems) even when the renegotiation is secure (i.e. there's no MitM, just the two endpoints). Draft-ietf-tls-renegotiation-00 requires that even clients/servers that do implement secure renegotiation MUST NOT by default allow certificate changes during renegotiation (unless the application especially asks for it, and is prepared to handle such changes). Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Wed Nov 25 05:03:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523D328C10A for ; Wed, 25 Nov 2009 05:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 iEcYdDaQlm-O for ; Wed, 25 Nov 2009 05:03:35 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0B3E128C108 for ; Wed, 25 Nov 2009 05:03:34 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPD3Adu010694; Wed, 25 Nov 2009 15:03:25 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:03:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:03:20 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 25 Nov 2009 14:03:19 +0100 From: To: Date: Wed, 25 Nov 2009 14:03:18 +0100 Thread-Topic: [TLS] Server-only solution - proposed text Thread-Index: AcptRuXBLk5FVknXQ6SiLmsZeFWNLQAiIwIQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE531@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> <4B0C4580.2060403@extendedsubset.com> In-Reply-To: <4B0C4580.2060403@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 13:03:20.0332 (UTC) FILETIME=[A986C4C0:01CA6DCF] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:03:36 -0000 Hi Marsh, You're right that such applications could exist, but it seems their problems are quite independent of renegotiation. Even if all clients and servers implement the new secure renegotiation fix, the MitM could just forward the handshake messages as-is (so it would look like an initial handshake to both the client and the server)....? Best regards, Pasi (not wearing any hats) > -----Original Message----- > From: ext Marsh Ray [mailto:marsh@extendedsubset.com] > Sent: 24 November, 2009 22:44 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: yaronf@checkpoint.com; tls@ietf.org > Subject: Re: [TLS] Server-only solution - proposed text >=20 > Pasi.Eronen@nokia.com wrote: > > Earlier Eric noted that if no application data is exchanged between > the > > initial and renegotiation handshake (i.e. no application data is sent > > using the 1st session), this would be safe even without protocol > > changes. Should this be included in this section, too? >=20 > In order for that scenario to be 'safe' we would need to find some > language in the TLS spec, there since the beginning, which says that an > application MUST NOT attribute any semantics to the successful > authentication of the remote party. I don't believe the spec has any > such language. >=20 > There is probably some application out there which interprets a > connection from an authenticated client (or to an authenticated server) > as an "event" with real semantics. >=20 > Using SSH as an analogy, sometimes a login shell is set to, say, a > backup program. Commands get launched when the user authenticates. >=20 > Back with TLS, Microsoft IIS, for example, has a > client-certificate-to-user mapping facility. It's certainly possible > that the connection from such authenticated clients could trigger > certain "non-idempotent" activities, even if just adding false log > records. >=20 > - Marsh From lists@drh-consultancy.demon.co.uk Wed Nov 25 05:13:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F121D28C122 for ; Wed, 25 Nov 2009 05:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 27sTNPuq0Su1 for ; Wed, 25 Nov 2009 05:13:03 -0800 (PST) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by core3.amsl.com (Postfix) with ESMTP id 6875228C110 for ; Wed, 25 Nov 2009 05:13:03 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49686 helo=[192.168.7.8]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10587) with esmtpa (authdaemon_plain:drh) id 1NDHg0-0004ye-FF (Exim 4.69) for tls@ietf.org (return-path ); Wed, 25 Nov 2009 13:12:57 +0000 Message-ID: <4B0D2D5B.2090906@drh-consultancy.demon.co.uk> Date: Wed, 25 Nov 2009 13:12:59 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:13:05 -0000 Stefan Santesson wrote: > On 09-11-25 10:39 AM, "Yoav Nir" wrote: > >>> S->C Signaling: >>> 1) Servers MUST include RI >> Since this violates the TLS specs, I think servers MUST include RI only if the >> client included RI. Otherwise, they MUST use the tbd "other signal" >> > > Well, it would gracefully violate this rule of TLS. But it would be > announced so it should not break anything... Or would it? > Personally I wouldn't mind this at all. Yes it is breaking the rules of the TLS spec but I'd prefer that to the other hacks (including the few I suggested). For that specific case we could require the extension be fixed (meaning it could be treated as an opaque blob to compare/add) to simplify implementation. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From Pasi.Eronen@nokia.com Wed Nov 25 05:18:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42AA3A6A41 for ; Wed, 25 Nov 2009 05:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 BiGQYD0hMPgT for ; Wed, 25 Nov 2009 05:18:32 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EFEFE3A68D6 for ; Wed, 25 Nov 2009 05:18:31 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPDI18T010099; Wed, 25 Nov 2009 07:18:26 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:18:22 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:18:17 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 25 Nov 2009 14:18:03 +0100 From: To: , Date: Wed, 25 Nov 2009 14:18:03 +0100 Thread-Topic: [TLS] compression_method instead of server_version ? Thread-Index: Acptbdl0U4vJirowRg63A7BVcb33/QAYlebw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE55D@NOK-EUMSG-01.mgdnok.nokia.com> References: <4B0BE902.6070803@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Nov 24, 9 02:09:06 pm <200911250121.nAP1LD3J017142@fs4113.wdf.sap.corp> In-Reply-To: <200911250121.nAP1LD3J017142@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 13:18:17.0190 (UTC) FILETIME=[C0187060:01CA6DD1] X-Nokia-AV: Clean Subject: Re: [TLS] compression_method instead of server_version ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:18:32 -0000 Martin Rex wrote: > Since the value range of compression methods is partitioned, > shaving a single bit is IMHO not an option. I guess this depends on (a) whether anyone is actually using values from the "private use" range 224-255, and (b) if someone is, whether=20 the renegotiation fix has to be compatible with using "private use" compression algorithms. If we e.g. "borrowed" the most significant bit of the compression algorithm for S->C signalling, we could just require that a client that supports secure renegotiation MUST NOT include any compression methods in current private use range (224-255) in the ClientHello. I doubt anyone is using those currently; TLS compression in general is rarely used, and AFAIK those implementations that use it use the publicly defined algorithms (all of which have 0 in the most significant=20 bit). So this wouldn't be a code change for implementations... And we would need to update the IANA registration rules for this registry, and probably create a new private use range (e.g., 120-127), but that's just paperwork, not implementation work. > We would have to get a single compression_method assigned, > and then relocate the real "common compression_method" > that the server selected to a different location -- > Server.Random. >=20 > There seems to be an issue with some hardware/chips that may have an > issue with TLS version changing (and its happened before with > TLSv1.1...) I'd be very interested in any concrete data (even without=20 mentioning product names) about this... Best regards, Pasi (not wearing any hats) From yngve@opera.com Wed Nov 25 05:46:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000603A6A7D for ; Wed, 25 Nov 2009 05:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 7bYMdSWMqcIO for ; Wed, 25 Nov 2009 05:46:07 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 79AE73A6AA2 for ; Wed, 25 Nov 2009 05:46:07 -0800 (PST) Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAPDiOTI028293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2009 13:44:25 GMT Date: Wed, 25 Nov 2009 14:45:48 +0100 To: Pasi.Eronen@nokia.com, mrex@sap.com From: "Yngve Nysaeter Pettersen" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <808FD6E27AD4884E94820BC333B2DB774F310BB2AB@NOK-EUMSG-01.mgdnok.nokia.com> <200911232007.nANK736K022320@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F310FE52B@NOK-EUMSG-01.mgdnok.nokia.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310FE52B@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Opera Mail/9.65 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: yngve@opera.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:46:09 -0000 On Wed, 25 Nov 2009 14:01:19 +0100, wrote: > Having TLS endpoints change their certificates during renegotiation is > highly likely to confuse many applications (and lead to security Just an observation: A while back I encountered a big Asian bank whose loadbalanced servers were using two different Extended Validation certificates, and was switching between those certificates every other negotiation. The reason I was investigating the site was that the EV indication was flip-flopping on this site, which turned out to be because one certificate had a 1024 bit key (which qualifies for EV), the other was using a 1023 bit key (which does not qualify for EV). For reference, session resume did not work in this case. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From Pasi.Eronen@nokia.com Wed Nov 25 05:56:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207ED28C0E9 for ; Wed, 25 Nov 2009 05:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 D4HVtQn-6ywE for ; Wed, 25 Nov 2009 05:56:57 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D30333A6931 for ; Wed, 25 Nov 2009 05:56:56 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPDuGfu027668; Wed, 25 Nov 2009 15:56:49 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:56:33 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 15:56:14 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 25 Nov 2009 14:56:14 +0100 From: To: , Date: Wed, 25 Nov 2009 14:56:12 +0100 Thread-Topic: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt Thread-Index: AcpqymY8C8n7fthWT6WnHJZ/EqRYHADC/vCA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE5DF@NOK-EUMSG-01.mgdnok.nokia.com> References: <4B081A08.8010600@pobox.com> In-Reply-To: <4B081A08.8010600@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 13:56:14.0678 (UTC) FILETIME=[0D958760:01CA6DD7] X-Nokia-AV: Clean Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:56:58 -0000 I'm not so sure about the fail-safe argument (either way, the spec will be very short and simple, and there's not much we can do about truly incompetent implementors), but I agree this could be better aligned with future versions of TLS. Potentially, it could also simplify implementation if you don't have full TLS extension support (since the extension would always=20 be a fixed byte string). And since both parties already know the=20 data, we're not really gaining much by sending it over-the-wire... Best regards, Pasi (not wearing any hats) > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Michael D'Errico > Sent: 21 November, 2009 18:49 > To: tls@ietf.org > Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation- > 00.txt >=20 > Since the tide is going in the direction of this draft, I suggest the > following change to make it fail-safe rather than have the flaw I > pointed out in this message: >=20 > http://www.ietf.org/mail-archive/web/tls/current/msg04582.html >=20 > The change I propose is simple: >=20 > - the extension is sent on every handshake and is always empty > - the previous verify_data is added to the Finished calculation > but not sent over the wire >=20 > The latter should be done in the way that we want moving forward to > future versions of TLS. I have implemented it by putting it in the > handshake message stream immediately following the ServerHello; if > that is undesirable long-term, please suggest an improvement. >=20 > Mike >=20 >=20 > Joseph Salowey (jsalowey) wrote: > > We have had a lot of good discussion on this list, but I think we > need > > to start converging on a solution. As I said in a previous message, > I've > > asked Eric to serve as editor for the WG draft and he has posted > > draft-ietf-tls-renegotiation-00 as a starting point. I realize that > > there are a number of people who aren't happy with aspects of the > draft, > > or indeed with the draft as a whole, but I'd like to get the sense > for > > the feelings of the group as a whole. If we have rough consensus that > > this is a workable approach, we can try to nail down the remaining > > issues and move forward. > > > > To try to keep this concrete, please respond with answers to this > > question: > > > > Support for the draft: > > - I support this draft > > - I support this draft with the following modification > > - I would support an entirely different proposal (please identify it; > be > > specific) > > > > If you are proposing a modification, in addition to providing a > > description and rationale for a modification to the document it is > > helpful to provide sample text of the modification. Also, please > > indicate whether you would only support the draft with your > modification > > or whether you can live with it unmodified. > > > > Thanks, > > > > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Wed Nov 25 06:10:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0703A68AB for ; Wed, 25 Nov 2009 06:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.092, 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 QEsbUZODIlel for ; Wed, 25 Nov 2009 06:10:02 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 3EF033A682A for ; Wed, 25 Nov 2009 06:10:02 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPE9tXd001790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 15:09:56 +0100 (MET) From: Martin Rex Message-Id: <200911251409.nAPE9nCs013164@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Wed, 25 Nov 2009 15:09:49 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310FE55D@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 25, 9 02:18:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] compression_method instead of server_version ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:10:03 -0000 Yoav Nir wrote: > Dr. Stephen Henson wrote: > > > > Could use one bit of the compression_method field in ServerHello. > > Since there are only two actually defined since it first appeared > > in SSLv3 I don't think we'll run out any time soon. > > Well, since we're adding information without increasing the size of > the messages, I guess it really is a compression method. I like this rationale! :-) > Martin Rex wrote: > > > Since the value range of compression methods is partitioned, > > shaving a single bit is IMHO not an option. For reference what I'm referring to: http://www.iana.org/assignments/comp-meth-ids/comp-meth-ids.xhtml Pasi.Eronen@nokia.com wrote: > > I guess this depends on (a) whether anyone is actually using values > from the "private use" range 224-255, and (b) if someone is, whether > the renegotiation fix has to be compatible with using "private use" > compression algorithms. > > If we e.g. "borrowed" the most significant bit of the compression > algorithm for S->C signalling, we could just require that a client > that supports secure renegotiation MUST NOT include any compression > methods in current private use range (224-255) in the ClientHello. > > I doubt anyone is using those currently; TLS compression in general > is rarely used, and AFAIK those implementations that use it use the > publicly defined algorithms (all of which have 0 in the most significant > bit). So this wouldn't be a code change for implementations... > > And we would need to update the IANA registration rules for this > registry, and probably create a new private use range (e.g., 120-127), > but that's just paperwork, not implementation work. Using ServerHello.compression_method ServerHello.server_version for S->C signaling would be fine with me if it improves the acceptance of the extension-less approach. I'm also not generally opposed to shaving a bit, but considering the existing allocation rules, it is not my first choice. Again, consensus is much more important than personal taste for me. What I would really appreciate is feedback from _implementors_ on the alternatives, because they're the ones who will put the fix into code an interoperate. There may be hardware (implementing or supporting TLS at endpoints) affected as well, which might be much more difficult to patch than software. So feedback from those would be helpful! -Martin From stephen.farrell@cs.tcd.ie Wed Nov 25 07:23:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11D428C240 for ; Wed, 25 Nov 2009 07:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfIwMA2niaHV for ; Wed, 25 Nov 2009 07:23:53 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id F143A28C22F for ; Wed, 25 Nov 2009 07:23:52 -0800 (PST) Received: from mail137-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 8.1.340.0; Wed, 25 Nov 2009 15:23:47 +0000 Received: from mail137-tx2 (localhost.localdomain [127.0.0.1]) by mail137-tx2-R.bigfish.com (Postfix) with ESMTP id 78903EF8473; Wed, 25 Nov 2009 15:23:47 +0000 (UTC) X-SpamScore: -36 X-BigFish: VPS-36(zz1432R98dNzz1202hzz1033ILz2dh87h6bh61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail137-tx2 (localhost.localdomain [127.0.0.1]) by mail137-tx2 (MessageSwitch) id 1259162597357744_29366; Wed, 25 Nov 2009 15:23:17 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.243]) by mail137-tx2.bigfish.com (Postfix) with ESMTP id A8B534F806A; Wed, 25 Nov 2009 15:23:16 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server id 14.0.482.32; Wed, 25 Nov 2009 15:23:16 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 75C3B68005; Wed, 25 Nov 2009 15:23:15 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A06FC0720CF; Wed, 25 Nov 2009 15:23:15 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 599DF68005; Wed, 25 Nov 2009 15:23:15 +0000 (GMT) Message-ID: <4B0D4BE8.6080605@cs.tcd.ie> Date: Wed, 25 Nov 2009 15:23:20 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B080E9A.5030302@cs.tcd.ie> In-Reply-To: <4B080E9A.5030302@cs.tcd.ie> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A16FC0720CF X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.28) X-Reverse-DNS: imx2.tcd.ie Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:23:53 -0000 Having now read Martin's draft I still think that draft-ietf-tls-renegotiation is the way to go and further think that that should be progressed asap. I would however support the later publication of a version of draft-mrex-tls-secure-renegotiation that only addressed old versions not covered by draft-ietf-tls-renegotiation. The only reason for "later" here is that I suspect from the list traffic that finishing that I-D might take a while. I don't think draft-ietf-tls-renegotiation should wait on that. If the above turned out to be the plan then I guess the magic ciphersuite might no longer be needed in draft-ietf-tls-renegotiation. S. Stephen Farrell wrote: > > Joseph Salowey (jsalowey) wrote: >> Support for the draft: >> - I support this draft >> - I support this draft with the following modification >> - I would support an entirely different proposal (please identify it; be >> specific) > > I support this draft for fixing TLS. > > If another draft emerges in a timely fashion that better addresses > SSL then I might support that as well (either as a separate document > or incorporated into this one). So far I can't tell if an SSL solution > is worthwhile - despite all the words on the list, there's no I-D. > > S. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From stephen.farrell@cs.tcd.ie Wed Nov 25 07:34:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7511B3A6863 for ; Wed, 25 Nov 2009 07:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPCjrLAqbOyf for ; Wed, 25 Nov 2009 07:34:23 -0800 (PST) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.15]) by core3.amsl.com (Postfix) with ESMTP id B415E3A6861 for ; Wed, 25 Nov 2009 07:34:23 -0800 (PST) Received: from mail160-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 8.1.340.0; Wed, 25 Nov 2009 15:34:18 +0000 Received: from mail160-va3 (localhost.localdomain [127.0.0.1]) by mail160-va3-R.bigfish.com (Postfix) with ESMTP id 40DF7BE046D; Wed, 25 Nov 2009 15:34:18 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzzz2dh6bh87h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail160-va3 (localhost.localdomain [127.0.0.1]) by mail160-va3 (MessageSwitch) id 125916325550599_26066; Wed, 25 Nov 2009 15:34:15 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.242]) by mail160-va3.bigfish.com (Postfix) with ESMTP id EFA2B280051; Wed, 25 Nov 2009 15:34:14 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server id 14.0.482.32; Wed, 25 Nov 2009 15:34:14 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id F209D68006; Wed, 25 Nov 2009 15:34:13 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A07456EE4B6; Wed, 25 Nov 2009 15:34:13 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id DC69F68006; Wed, 25 Nov 2009 15:34:13 +0000 (GMT) Message-ID: <4B0D4E7A.7040709@cs.tcd.ie> Date: Wed, 25 Nov 2009 15:34:18 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Dr Stephen Henson References: <4B0D2D5B.2090906@drh-consultancy.demon.co.uk> In-Reply-To: <4B0D2D5B.2090906@drh-consultancy.demon.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A17456EE4B6 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.28) X-Reverse-DNS: imx2.tcd.ie Cc: "tls@ietf.org" Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:34:24 -0000 Apologies in advance if this was already dismissed, its hard to keep track of all the options offered already. Another option for older versions that don't use RI. How about a new server_hello_done_patched HandshakeType value? S. From mrex@sap.com Wed Nov 25 08:43:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063293A6AE7 for ; Wed, 25 Nov 2009 08:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.091, 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 BIAU+ZYW6Z6b for ; Wed, 25 Nov 2009 08:43:53 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 11D153A6ADF for ; Wed, 25 Nov 2009 08:43:52 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPGhhki019096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 17:43:43 +0100 (MET) From: Martin Rex Message-Id: <200911251643.nAPGhg8Y004949@fs4113.wdf.sap.corp> To: stephen.farrell@cs.tcd.ie (Stephen Farrell) Date: Wed, 25 Nov 2009 17:43:42 +0100 (MET) In-Reply-To: <4B0D4E7A.7040709@cs.tcd.ie> from "Stephen Farrell" at Nov 25, 9 03:34:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:43:54 -0000 Stephen Farrell wrote: > > Apologies in advance if this was already dismissed, its > hard to keep track of all the options offered already. > > Another option for older versions that don't use RI. > > How about a new server_hello_done_patched HandshakeType > value? We don't have ServerHelloDone in TLS session resume (initial handshake on a connection). If we are sure to make it a session property on the full handshake that created this session (independent whether initial or renegotiation), it might work. I'm not sufficiently familiar with modified TLS handshakes, to make an assesment for them (didn't EAP use a modified handshake)? -Martin From marsh@extendedsubset.com Wed Nov 25 08:44:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D34F3A6AE6 for ; Wed, 25 Nov 2009 08:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 BTR1uYCyOt+p for ; Wed, 25 Nov 2009 08:44:50 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id AF4263A6AE1 for ; Wed, 25 Nov 2009 08:44:47 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDKyt-000LPh-J7; Wed, 25 Nov 2009 16:44:41 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7B347603A; Wed, 25 Nov 2009 16:44:38 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/+Ne8/GbxQQi82e1LMMq/ibJd1Rwet3sA= Message-ID: <4B0D5EF3.3020905@extendedsubset.com> Date: Wed, 25 Nov 2009 10:44:35 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: yangqinqin References: <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com> <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> In-Reply-To: <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:44:51 -0000 yangqinqin wrote: > Marsh, > > Thank you for your reply. I have just joined the mailing list. > > In your draft, "If the other end attempts to authenticate with a > different identity, the renegotiation MUST fail." > > How do you achieve it in the renegotiation? > > You also wrote in the draft, "For certificate based cipher suites, > this means bitwise equality of the end-entity certificate. " > > This increases authentication steps. But original TLS renegotiation > protocol has not this step. Yeah, I don't know how that got in there. I certainly didn't put it in, and I do not think it has any place in the TLS spec. - Marsh From marsh@extendedsubset.com Wed Nov 25 08:53:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B317B3A6AB5 for ; Wed, 25 Nov 2009 08:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 vRWPwGYyvF-g for ; Wed, 25 Nov 2009 08:53:30 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id CF82B3A6AA3 for ; Wed, 25 Nov 2009 08:53:30 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDL7N-000PaQ-K7; Wed, 25 Nov 2009 16:53:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 16EA9603A; Wed, 25 Nov 2009 16:53:23 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/thfl5Mk/Cd2xYIzI8Pv9cz5x+OWjWcVU= Message-ID: <4B0D6100.7080009@extendedsubset.com> Date: Wed, 25 Nov 2009 10:53:20 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> <4B0C4580.2060403@extendedsubset.com> <808FD6E27AD4884E94820BC333B2DB774F310FE531@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310FE531@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:53:31 -0000 >> -----Original Message----- >> From: ext Marsh Ray [mailto:marsh@extendedsubset.com] >> Sent: 24 November, 2009 22:44 >> To: Eronen Pasi (Nokia-NRC/Helsinki) >> Cc: yaronf@checkpoint.com; tls@ietf.org >> Subject: Re: [TLS] Server-only solution - proposed text >> >> Pasi.Eronen@nokia.com wrote: >>> Earlier Eric noted that if no application data is exchanged between >> the >>> initial and renegotiation handshake (i.e. no application data is sent >>> using the 1st session), this would be safe even without protocol >>> changes. Should this be included in this section, too? >> In order for that scenario to be 'safe' we would need to find some >> language in the TLS spec, there since the beginning, which says that an >> application MUST NOT attribute any semantics to the successful >> authentication of the remote party. I don't believe the spec has any >> such language. >> >> There is probably some application out there which interprets a >> connection from an authenticated client (or to an authenticated server) >> as an "event" with real semantics. >> >> Using SSH as an analogy, sometimes a login shell is set to, say, a >> backup program. Commands get launched when the user authenticates. >> >> Back with TLS, Microsoft IIS, for example, has a >> client-certificate-to-user mapping facility. It's certainly possible >> that the connection from such authenticated clients could trigger >> certain "non-idempotent" activities, even if just adding false log >> records. >> >> - Marsh Pasi.Eronen@nokia.com wrote: > Hi Marsh, > > You're right that such applications could exist, but it seems their > problems are quite independent of renegotiation. > > Even if all clients and servers implement the new secure renegotiation > fix, the MitM could just forward the handshake messages as-is (so it > would look like an initial handshake to both the client and the > server)....? Oh @(#$&! Is there nothing in the spec which stops the client from flushing his output buffer down an insecure channel at that point?! Sure, supposedly he should have waited for the server's Finished message and checked the cert and all that. But if he implemented the cert checking in a callback (as he should), that might not process until the server's Finished message arrives (which never happens because MitM drops it). - Marsh From ekr@networkresonance.com Wed Nov 25 08:54:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8050C3A6ADE for ; Wed, 25 Nov 2009 08:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtkzhCvhNz5S for ; Wed, 25 Nov 2009 08:54:53 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id D81673A6AB5 for ; Wed, 25 Nov 2009 08:54:53 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id A2CDA6C3173; Wed, 25 Nov 2009 08:55:22 -0800 (PST) Date: Wed, 25 Nov 2009 08:55:22 -0800 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B0D5EF3.3020905@extendedsubset.com> References: <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com> <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> <4B0D5EF3.3020905@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091125165522.A2CDA6C3173@kilo.networkresonance.com> Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:54:54 -0000 At Wed, 25 Nov 2009 10:44:35 -0600, Marsh Ray wrote: > > yangqinqin wrote: > > Marsh, > > > > Thank you for your reply. I have just joined the mailing list. > > > > In your draft, "If the other end attempts to authenticate with a > > different identity, the renegotiation MUST fail." > > > > How do you achieve it in the renegotiation? > > > > You also wrote in the draft, "For certificate based cipher suites, > > this means bitwise equality of the end-entity certificate. " > > > > This increases authentication steps. But original TLS renegotiation > > protocol has not this step. > > > Yeah, I don't know how that got in there. > > I certainly didn't put it in, and I do not think it has any place in the > TLS spec. As I said, Pasi Eronen suggested it and it seemed sound to me. I'm not wedded to it and if the WG feels that it's a bad idea, I'll gladly take it out. Pasi? -Ekr From Pasi.Eronen@nokia.com Wed Nov 25 09:11:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57733A6AF0 for ; Wed, 25 Nov 2009 09:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 HJBC8n4rxLIx for ; Wed, 25 Nov 2009 09:11:18 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 5C64D3A6AB4 for ; Wed, 25 Nov 2009 09:11:17 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPHALBx026692; Wed, 25 Nov 2009 19:11:07 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 19:11:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 19:10:57 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 25 Nov 2009 18:10:57 +0100 From: To: Date: Wed, 25 Nov 2009 18:10:55 +0100 Thread-Topic: [TLS] Server-only solution - proposed text Thread-Index: Acpt79C1RH9T5OyxRQay9zzrILYnQAAAbveA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE8B2@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> <4B0C4580.2060403@extendedsubset.com> <808FD6E27AD4884E94820BC333B2DB774F310FE531@NOK-EUMSG-01.mgdnok.nokia.com> <4B0D6100.7080009@extendedsubset.com> In-Reply-To: <4B0D6100.7080009@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 17:10:57.0436 (UTC) FILETIME=[410CEDC0:01CA6DF2] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:11:19 -0000 Marsh Ray wrote: > > You're right that such applications could exist, but it seems their > > problems are quite independent of renegotiation. > > > > Even if all clients and servers implement the new secure > > renegotiation fix, the MitM could just forward the handshake > > messages as-is (so it would look like an initial handshake to both > > the client and the server)....? >=20 > Oh @(#$&! >=20 > Is there nothing in the spec which stops the client from flushing > his output buffer down an insecure channel at that point?! > > Sure, supposedly he should have waited for the server's Finished > message and checked the cert and all that. But if he implemented the > cert checking in a callback (as he should), that might not process > until the server's Finished message arrives (which never happens > because MitM drops it). The client MUST wait for the server's Finished message and verify it before sending (or accepting) any application data. But in the examples you gave, there was no application data -- the "event" was triggered just by a successful handshake. So the MitM doesn't actually have to drop any messages, either, just forward all packets unchanged (which doesn't really count as=20 an "attack", even...) Best regards, Pasi (not wearing any hats) From noskov@microsoft.com Wed Nov 25 09:21:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE3A3A6AF6 for ; Wed, 25 Nov 2009 09:21:28 -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 w0lVoCcU-s4r for ; Wed, 25 Nov 2009 09:21:28 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 1194C3A6AF4 for ; Wed, 25 Nov 2009 09:21:28 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 Nov 2009 09:21:47 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 25 Nov 2009 09:21:22 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 25 Nov 2009 09:21:02 -0800 From: Nasko Oskov To: Eric Rescorla , Marsh Ray Thread-Topic: [TLS] some questions for your draft Thread-Index: AQHKbaw1gs9E5dgW2EGnpw7vVM9jX5FHh+eAgAADAwD//4CIMA== Date: Wed, 25 Nov 2009 17:19:23 +0000 Deferred-Delivery: Wed, 25 Nov 2009 17:20:00 +0000 Message-ID: References: <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com> <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> <4B0D5EF3.3020905@extendedsubset.com> <20091125165522.A2CDA6C3173@kilo.networkresonance.com> In-Reply-To: <20091125165522.A2CDA6C3173@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:21:29 -0000 Eric Rescorla wrote: >At Wed, 25 Nov 2009 10:44:35 -0600, >Marsh Ray wrote: >>=20 >> yangqinqin wrote: >> > Marsh, >> >=20 >> > Thank you for your reply. I have just joined the mailing list. >> >=20 >> > In your draft, "If the other end attempts to authenticate with a=20 >> > different identity, the renegotiation MUST fail." >> >=20 >> > How do you achieve it in the renegotiation? >> >=20 >> > You also wrote in the draft, "For certificate based cipher suites,=20 >> > this means bitwise equality of the end-entity certificate. " >> >=20 >> > This increases authentication steps. But original TLS renegotiation=20 >> > protocol has not this step. >>=20 >>=20 >> Yeah, I don't know how that got in there. >> >> I certainly didn't put it in, and I do not think it has any place in=20 >> the TLS spec. > >As I said, Pasi Eronen suggested it and it seemed sound to me. > >I'm not wedded to it and if the WG feels that it's a bad idea, I'll gladly >take it out. Pasi? I would suggest we don't modify this behavior as part of the fix. Someone already mentioned load balancers that change certs on renegotiation. At the very least this could be a SHOULD instead of MUST. The way I read it, it prevents the current client auth implementations, since it disallows change of identity (from anon to authenticated). Nasko From mrex@sap.com Wed Nov 25 09:24:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568243A6AB4 for ; Wed, 25 Nov 2009 09:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.091, 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 Gt7vffe3ypRx for ; Wed, 25 Nov 2009 09:24:31 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 471C83A6A62 for ; Wed, 25 Nov 2009 09:24:31 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPHOM5o010737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 18:24:22 +0100 (MET) From: Martin Rex Message-Id: <200911251724.nAPHOMf2007151@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Wed, 25 Nov 2009 18:24:22 +0100 (MET) In-Reply-To: <20091125165522.A2CDA6C3173@kilo.networkresonance.com> from "Eric Rescorla" at Nov 25, 9 08:55:22 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:24:32 -0000 I'm actually very favourable of a restriction that already established identities (not the lack thereof!) must not change during renegotiaton, and contemplating to add this into my proposal as well. http://www.ietf.org/mail-archive/web/tls/current/msg04136.html http://www.ietf.org/mail-archive/web/tls/current/msg04132.html http://www.ietf.org/mail-archive/web/tls/current/msg04091.html -Martin Eric Rescorla wrote: > > At Wed, 25 Nov 2009 10:44:35 -0600, > Marsh Ray wrote: > > > > yangqinqin wrote: > > > Marsh, > > > > > > Thank you for your reply. I have just joined the mailing list. > > > > > > In your draft, "If the other end attempts to authenticate with a > > > different identity, the renegotiation MUST fail." > > > > > > How do you achieve it in the renegotiation? > > > > > > You also wrote in the draft, "For certificate based cipher suites, > > > this means bitwise equality of the end-entity certificate. " > > > > > > This increases authentication steps. But original TLS renegotiation > > > protocol has not this step. > > > > > > Yeah, I don't know how that got in there. > > > > I certainly didn't put it in, and I do not think it has any place in the > > TLS spec. > > As I said, Pasi Eronen suggested it and it seemed sound to me. > > I'm not wedded to it and if the WG feels that it's a bad idea, I'll > gladly take it out. Pasi? From marsh@extendedsubset.com Wed Nov 25 09:29:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA7328C135 for ; Wed, 25 Nov 2009 09:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 x9d-F1P+zNpG for ; Wed, 25 Nov 2009 09:29:34 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id C3B8B3A6843 for ; Wed, 25 Nov 2009 09:29:34 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDLgH-000ESK-Kl; Wed, 25 Nov 2009 17:29:29 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0354B603A; Wed, 25 Nov 2009 17:29:27 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/d0siDld+P4fch0V0SwzBuLgAiC/Y5Spo= Message-ID: <4B0D6975.8040501@extendedsubset.com> Date: Wed, 25 Nov 2009 11:29:25 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> <4B0C4580.2060403@extendedsubset.com> <808FD6E27AD4884E94820BC333B2DB774F310FE531@NOK-EUMSG-01.mgdnok.nokia.com> <4B0D6100.7080009@extendedsubset.com> <808FD6E27AD4884E94820BC333B2DB774F310FE8B2@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310FE8B2@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:29:35 -0000 Pasi.Eronen@nokia.com wrote: > > The client MUST wait for the server's Finished message and verify it > before sending (or accepting) any application data. But in the > examples you gave, there was no application data -- the "event" was > triggered just by a successful handshake. OK, I found it http://tools.ietf.org/html/rfc5246 : > Once a side > has sent its Finished message and received and validated the > Finished message from its peer, it may begin to send and receive > application data over the connection. OK, forget the client's data then. However, I don't see anything that stops the server from sending plaintext encrypted with a compromised key to a client which was successfully authenticated by client certificate. > So the MitM doesn't actually have to drop any messages, either, just > forward all packets unchanged (which doesn't really count as > an "attack", even...) Well, MitM might want to rig up a compromised key for the server to transmit with. The client doesn't seem to be able to fully validate the server's cert until he receives the Finished message. Maybe he could do some checking in theory, but not completely, otherwise what would the Finished message be for? So a server application can receive a connection, properly validate the client certificate, and write an unlimited amount of data which is encrypted by a compromised key. I'm probably missing something, what is it? - Marsh From marsh@extendedsubset.com Wed Nov 25 09:33:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38BF3A67F4 for ; Wed, 25 Nov 2009 09:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 V9EHcl2F9wpq for ; Wed, 25 Nov 2009 09:33:56 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 50BB03A6AB6 for ; Wed, 25 Nov 2009 09:33:56 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDLkV-000FFw-0W for tls@ietf.org; Wed, 25 Nov 2009 17:33:51 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E124C603A for ; Wed, 25 Nov 2009 17:33:49 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18LfgI4OZ2g8o6GBxvhLmsvNUulETv7GvA= Message-ID: <4B0D6A7B.1040803@extendedsubset.com> Date: Wed, 25 Nov 2009 11:33:47 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls >> \"tls@ietf.org\"" References: <200911251724.nAPHOMf2007151@fs4113.wdf.sap.corp> In-Reply-To: <200911251724.nAPHOMf2007151@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:33:57 -0000 Martin Rex wrote: > I'm actually very favourable of a restriction that already established > identities (not the lack thereof!) must not change during renegotiaton, > and contemplating to add this into my proposal as well. I believe the current TLS specs do not have a sufficiently rigorous definition of "identity" in order to be mandating restrictions like this. memcmp() of certs doesn't cut it. At best, they will be ignored. At worst, they will entice developers to make unsafe assumptions. - Marsh From mrex@sap.com Wed Nov 25 09:34:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF9328C135 for ; Wed, 25 Nov 2009 09:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 js8VgI3XSHP6 for ; Wed, 25 Nov 2009 09:34:15 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 358F328C10D for ; Wed, 25 Nov 2009 09:34:15 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAPHY7Qn001113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 18:34:07 +0100 (MET) From: Martin Rex Message-Id: <200911251734.nAPHY68d008080@fs4113.wdf.sap.corp> To: noskov@microsoft.com (Nasko Oskov) Date: Wed, 25 Nov 2009 18:34:06 +0100 (MET) In-Reply-To: from "Nasko Oskov" at Nov 25, 9 05:19:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:34:16 -0000 Nasko Oskov wrote: > > I would suggest we don't modify this behavior as part of the fix. Someone > already mentioned load balancers that change certs on renegotiation. At the > very least this could be a SHOULD instead of MUST. I haven't fully understood the scenario the Yngve described. On a regular renegotiation (full handshake followed by a renegotiation) this is not going to happen, unless a MitM is performed. I assume that it happens on an attempted TLS session resume for which the server performs a full handshake instead. If the client has a problem with the identity change from the failed proposed resume to the successful full handshake, then this is a client problem. I consider it somewhat unlikely (but not impossible) that the backend infrastructure behind that loadbalancer shares TLS session caches but not TLS credentials. > > The way I read it, it prevents the current client auth implementations, > since it disallows change of identity (from anon to authenticated). This interpretation might be non-intentional. I would assume that changing state from non-authenticated to authenticated during renegotiation, as it is current practice with delayed client authentication, is not what this requirement intended to prohibit in the future. -Martin From mike-list@pobox.com Wed Nov 25 09:53:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A803A6AF5 for ; Wed, 25 Nov 2009 09:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 OkYEbTEYN-VA for ; Wed, 25 Nov 2009 09:52:59 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 604313A6AE7 for ; Wed, 25 Nov 2009 09:52:59 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EF4CC82132 for ; Wed, 25 Nov 2009 12:52:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=1W3wlQ11huTM uLqZ00hTwQK4m1U=; b=c/EDsNzTkdtkgHg7lK0ZTketNgDDPO8Ajc8qrdvOPLNt 6n/qO3fX1s751zO+PdB13UU83KAnsOiEzFWHoyi4JDu3gt77rwRhFY3lJU11zrmq YRndsmWYta9XVUuajKPazblMWIcwLIPFiA4oUFrmjxzUHPPakhXyAaO+gBseJSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Q6EM3I TvQ1gxs05/7sMKgpxLSFBp6UBlNvg05MGdjQ7QLsoBQMny/NIyZjL9/QJmnzRaw+ Y4FZQ94+vdacuNxVYl1Ae4gbYYhX+z9qqNYlGP6eesMQFRd1kHSm/yDhXT476qRi T5rT6IoE/0m0Y9S3DgYFSDP4mX7ghfNIZKLNo= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EC30B82130 for ; Wed, 25 Nov 2009 12:52:53 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 4E4508212E for ; Wed, 25 Nov 2009 12:52:53 -0500 (EST) Message-ID: <4B0D6F42.1060102@pobox.com> Date: Wed, 25 Nov 2009 09:54:10 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B081A08.8010600@pobox.com> <808FD6E27AD4884E94820BC333B2DB774F310FE5DF@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310FE5DF@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 5B40E272-D9EB-11DE-8171-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:53:00 -0000 The proposed change (empty extension in both directions on every handshake + incorporate previous verify_data into new Finished) has some nice benefits over the current RI proposal: - it is simple for clients to add even if they do not currently support extensions since all that is needed is to append a FIXED 6-byte sequence to ClientHello: 00 04 FF 02 00 00 (where FF 02 is the new extension number) - since a server can only respond with extensions asked for by the client, they can either respond with nothing (secure renegotiation not supported) or the exact same 6 bytes! (which is easy for the client to detect) - no need to pack the verify_data into the extension when sending - no need to extract the verify_data from the received extension - not possible to forget to check that the verify_data is correct (since the already-existing Finished check does that) All of this leads to less code, and is more aligned with what we want moving into the future. (Nobody would argue that sending the old verify_data in an extension would be the preferred way to fix this for TLS 1.3 would they?) Mike Pasi.Eronen@nokia.com wrote: > I'm not so sure about the fail-safe argument (either way, the spec > will be very short and simple, and there's not much we can do about > truly incompetent implementors), but I agree this could be better > aligned with future versions of TLS. > > Potentially, it could also simplify implementation if you don't > have full TLS extension support (since the extension would always > be a fixed byte string). And since both parties already know the > data, we're not really gaining much by sending it over-the-wire... > > Best regards, > Pasi > (not wearing any hats) > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> ext Michael D'Errico >> Sent: 21 November, 2009 18:49 >> To: tls@ietf.org >> Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation- >> 00.txt >> >> Since the tide is going in the direction of this draft, I suggest the >> following change to make it fail-safe rather than have the flaw I >> pointed out in this message: >> >> http://www.ietf.org/mail-archive/web/tls/current/msg04582.html >> >> The change I propose is simple: >> >> - the extension is sent on every handshake and is always empty >> - the previous verify_data is added to the Finished calculation >> but not sent over the wire >> >> The latter should be done in the way that we want moving forward to >> future versions of TLS. I have implemented it by putting it in the >> handshake message stream immediately following the ServerHello; if >> that is undesirable long-term, please suggest an improvement. >> >> Mike >> >> >> Joseph Salowey (jsalowey) wrote: >>> We have had a lot of good discussion on this list, but I think we >> need >>> to start converging on a solution. As I said in a previous message, >> I've >>> asked Eric to serve as editor for the WG draft and he has posted >>> draft-ietf-tls-renegotiation-00 as a starting point. I realize that >>> there are a number of people who aren't happy with aspects of the >> draft, >>> or indeed with the draft as a whole, but I'd like to get the sense >> for >>> the feelings of the group as a whole. If we have rough consensus that >>> this is a workable approach, we can try to nail down the remaining >>> issues and move forward. >>> >>> To try to keep this concrete, please respond with answers to this >>> question: >>> >>> Support for the draft: >>> - I support this draft >>> - I support this draft with the following modification >>> - I would support an entirely different proposal (please identify it; >> be >>> specific) >>> >>> If you are proposing a modification, in addition to providing a >>> description and rationale for a modification to the document it is >>> helpful to provide sample text of the modification. Also, please >>> indicate whether you would only support the draft with your >> modification >>> or whether you can live with it unmodified. >>> >>> Thanks, >>> >>> Joe >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From mrex@sap.com Wed Nov 25 10:12:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E283A6953 for ; Wed, 25 Nov 2009 10:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.089, 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 f1uUbhfcfj4t for ; Wed, 25 Nov 2009 10:12:53 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 62E893A6AFF for ; Wed, 25 Nov 2009 10:12:50 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAPICi9p015824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 19:12:44 +0100 (MET) From: Martin Rex Message-Id: <200911251812.nAPIChHs011010@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 25 Nov 2009 19:12:43 +0100 (MET) In-Reply-To: <4B0D6F42.1060102@pobox.com> from "Michael D'Errico" at Nov 25, 9 09:54:10 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:12:55 -0000 Michael D'Errico wrote: > > The proposed change (empty extension in both directions on every > handshake + incorporate previous verify_data into new Finished) has > some nice benefits over the current RI proposal: The are currently TLS servers that will send back unsolicited TLS extensions to the client if a particular ciphersuite (a real one) is selected. One of the reasons they're doing this is the lack of support for sending TLS extensions in the ClientHello on WinXP and Win2003 platforms (for Cryptographic Service Providers). It's funny that WinXP/Win2003, although not able or willing to send TLS extensions in ClientHello, do not seem to barf on unsolicited ServerHelloExtensions in the server's reply, and instead make it somehow available for the Cryptographic Service Provider. So for any solution that involves an extension-less C->S signaling, and a reply in additional data trailing ServerHello, this data IMHO _needs_ to be a correctly formatted TLS extension, and the client must be prepared to receive more than one unsolicited TLS extension as reply and be able to tell them apart. I did complain loudly when first heard their server was sending unsolicited ServerHelloExtensions when that special cipher suite was negotiated, but I do have a little empathy for their solution. At least they correctly wrapped it as a TLS extension and did not just append arbitrary data to ServerHello. -Martin From marsh@extendedsubset.com Wed Nov 25 10:19:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A263A68BD for ; Wed, 25 Nov 2009 10:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 zMInEDv62ABw for ; Wed, 25 Nov 2009 10:19:43 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 0111D3A6870 for ; Wed, 25 Nov 2009 10:19:43 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDMSn-00055H-Oh; Wed, 25 Nov 2009 18:19:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id ECBD5603A; Wed, 25 Nov 2009 18:19:35 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+2f/wWxYpqyg4Bl5KS//WTSzUPY99vc7w= Message-ID: <4B0D7535.1050606@extendedsubset.com> Date: Wed, 25 Nov 2009 12:19:33 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B1DC@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F310BB3FB@NOK-EUMSG-01.mgdnok.nokia.com> <4B0C4580.2060403@extendedsubset.com> <808FD6E27AD4884E94820BC333B2DB774F310FE531@NOK-EUMSG-01.mgdnok.nokia.com> <4B0D6100.7080009@extendedsubset.com> <808FD6E27AD4884E94820BC333B2DB774F310FE8B2@NOK-EUMSG-01.mgdnok.nokia.com> <4B0D6975.8040501@extendedsubset.com> In-Reply-To: <4B0D6975.8040501@extendedsubset.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:19:43 -0000 Marsh Ray wrote: > > I'm probably missing something, what is it? To answer my own question, presumably the server is going to correctly validate the client's Finished message which covers the key data in question. Sorry for the confusion all. - Marsh From aerowolf@gmail.com Wed Nov 25 10:20:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D7D3A6983 for ; Wed, 25 Nov 2009 10:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 fVZ65DGxDeAr for ; Wed, 25 Nov 2009 10:20:23 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 79E383A67B1 for ; Wed, 25 Nov 2009 10:20:19 -0800 (PST) Received: by pxi16 with SMTP id 16so5653995pxi.29 for ; Wed, 25 Nov 2009 10:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g0u45bxatwOfY3USJm+zdalyNkan9oYBZ+5caN6Dlwg=; b=CSbdfC0wR0vwPwUCdZsjrbqP5RU0tzGhRJJQDN0YhDuLb6/tdS5E/mgc1nunGKFKBL 4pnp/cA0D7L37V/5JQvvup7CRV450kG0lsqfr53736dAepTV8X+Wu3yldbKQVI2q2ubz umucgpa8GAWZ0+Neb9IhbcLRuVhXL81iOfL1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZiBg358J6NtBXXXXL7Mpr5biUj59moHBq3m+8It2ilwDUC5SFUB/BDc2sJdQBx+ttB 93Odi/6zSSg2l/4T5gHviALEj0EADfSpdHtNQSPkfW6QU7cI+R3T5enYikbMaMZldpZT vb9FZUwpOEZORk52vJJ1u7hf4LPbusj4GMG18= MIME-Version: 1.0 Received: by 10.142.75.12 with SMTP id x12mr801951wfa.157.1259173210634; Wed, 25 Nov 2009 10:20:10 -0800 (PST) In-Reply-To: <200911250034.nAP0YLIQ014338@fs4113.wdf.sap.corp> References: <6b9359640911241522q6e31633bp3fd48bc2922c0cdf@mail.gmail.com> <200911250034.nAP0YLIQ014338@fs4113.wdf.sap.corp> Date: Wed, 25 Nov 2009 10:20:10 -0800 Message-ID: <6b9359640911251020j469c9bb2i4cd12a759e7c5ca2@mail.gmail.com> From: Kyle Hamilton To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:20:24 -0000 On Tue, Nov 24, 2009 at 4:34 PM, Martin Rex wrote: > Kyle Hamilton wrote: >> >> 4.3.1: >> Clients which choose to fall back to an extensionless mode of >> =C2=A0 =C2=A0operation MUST include the magic cipher suite [TBD] in any = such >> =C2=A0 =C2=A0handshake. =C2=A0Servers MUST reject any ClientHello which = uses this >> =C2=A0 =C2=A0cipher suite but does not include RI with a fatal "handshak= e_failure" >> =C2=A0 =C2=A0alert. =C2=A0Because servers ordinarily ignore unknown ciph= er suites, this >> =C2=A0 =C2=A0cipher suite can be added safely on any handshake, thus all= owing >> =C2=A0 =C2=A0detection and prevention of the MITM attack described above= . >> >> The only issue I see is... we've got an issue in signalling back to >> the client that it knows how to do the updated handshake. =C2=A0Would a >> slightly modified HelloRequest do it? > > Aha. =C2=A0Someone noticed that the S->C signaling is missing. > > I suggest using a bit in ServerHello.server_version. I don't think that many conforming clients are going to be okay with that, since they're sending {0x03 0x04}, and you're having the server send back {0x83 0x04} or {0x03 0x84}. The spec of TLS 1.0 implies that the client SHOULD terminate the connection if it receives back a higher major version number (or minor version number) than it was expecting. It is specified as "the lower of the client-suggested protocol version, and the protocol version supported by the server". It would be very easy to (falsely, in this case, but that doesn't matter) identify it as an MITM with a version modification attack going on. I think that conforming, unpatched TLS 1.0 implementations will terminate connections if they see a major version of 131, or a minor version of 132. -Kyle H > > So far, the magic cipher suite idea in TLS extension RI > is a "solution" to the downgrade vulnerability > from the automatic reconnect fallback in TLS clients. > > So as far as SSLv3 support is concern, TLS extension RI > is still firmly determined to exterminate SSLv3 =C2=A0and with the > magic cipher suite, it'll kill conservative TLS clients along with it. > > -Martin > > > From mrex@sap.com Wed Nov 25 10:25:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3473A6914 for ; Wed, 25 Nov 2009 10:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 DsTQ-qmjJApY for ; Wed, 25 Nov 2009 10:25:44 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 9EE823A68BD for ; Wed, 25 Nov 2009 10:25:44 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPIPbBF016413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 19:25:37 +0100 (MET) From: Martin Rex Message-Id: <200911251825.nAPIPamX012002@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 25 Nov 2009 19:25:36 +0100 (MET) In-Reply-To: <4B0D6A7B.1040803@extendedsubset.com> from "Marsh Ray" at Nov 25, 9 11:33:47 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:25:45 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > I'm actually very favourable of a restriction that already established > > identities (not the lack thereof!) must not change during renegotiaton, > > and contemplating to add this into my proposal as well. > > I believe the current TLS specs do not have a sufficiently rigorous > definition of "identity" in order to be mandating restrictions like > this. memcmp() of certs doesn't cut it. At best, they will be ignored. > At worst, they will entice developers to make unsafe assumptions. memcmp() of the certs is the only way TLS can implement this. This is the only concept of identical known to TLS. Equivalence between different certs (that may even come from different PKIs) is completely outside of the scope of TLS. As previous mentioned this is the last paragraph of the introduction of the TLS spec: The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. Yes, I'm aware that a memcmp() restriction is going to cause a disruption for Servers that both, actively use renegotiation and allow server certificates to be updated in-flight. (A lot of servers require a restart for replacing/updating the server certificate, though). If that is a concern for certain clients, then these clients must either implement a re-connect retry mechanism or provide an authentication (callback) function that will perform the necessary comparison of the server identity for renegotiation and can handle a server certificate renewal. -Martin From marsh@extendedsubset.com Wed Nov 25 10:29:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1B93A6944 for ; Wed, 25 Nov 2009 10:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 UGI-FIRtRoyI for ; Wed, 25 Nov 2009 10:29:18 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id E26E73A67A1 for ; Wed, 25 Nov 2009 10:29:14 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDMc1-000C0a-O4; Wed, 25 Nov 2009 18:29:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A8D51603A; Wed, 25 Nov 2009 18:29:07 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19MHjhw4T8wRmgMTiVUp5BAN5/tPn3DbBI= Message-ID: <4B0D7771.6050606@extendedsubset.com> Date: Wed, 25 Nov 2009 12:29:05 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kyle Hamilton References: <6b9359640911241522q6e31633bp3fd48bc2922c0cdf@mail.gmail.com> <200911250034.nAP0YLIQ014338@fs4113.wdf.sap.corp> <6b9359640911251020j469c9bb2i4cd12a759e7c5ca2@mail.gmail.com> In-Reply-To: <6b9359640911251020j469c9bb2i4cd12a759e7c5ca2@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:29:19 -0000 Kyle Hamilton wrote: > > I don't think that many conforming clients are going to be okay with > that, since they're sending {0x03 0x04}, and you're having the server > send back {0x83 0x04} or {0x03 0x84}. Only if they ask for it via the C->S signal. > I think that conforming, unpatched TLS 1.0 implementations will > terminate connections if they see a major version of 131, or a minor > version of 132. It doesn't get sent to unpatched implementations. Unpatched inspecting firewalls may raise an eyebrow, but in that case it's a question of least breakage. Short of changing the structure size with extensions or eliminating noticeable entropy from random_data, there has got to be some bit flipped which is currently assigned some other meaning. - Marsh From stefan@aaa-sec.com Wed Nov 25 10:30:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3448F3A6AEE for ; Wed, 25 Nov 2009 10:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df12G+rabL4h for ; Wed, 25 Nov 2009 10:30:07 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id B0C713A6AB4 for ; Wed, 25 Nov 2009 10:30:04 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 03D4E28B92E for ; Wed, 25 Nov 2009 19:30:05 +0100 (CET) Received: (qmail 78164 invoked from network); 25 Nov 2009 18:29:57 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Nov 2009 18:29:57 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 19:29:51 +0100 From: Stefan Santesson To: , Michael D'Errico Message-ID: Thread-Topic: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt Thread-Index: Acpt/UZ5I72gQ5nmNUaMWneBwfJCTQ== In-Reply-To: <200911251812.nAPIChHs011010@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:30:08 -0000 Martin, I feel less concerned about having the clients parse an extension. If they are already capable of handling one additional extension, it should not be too hard to handle another. Especially not if we follow Michael's suggestion and create an empty RI extension which is easy to add, detect and parse. /Stefan On 09-11-25 7:12 PM, "Martin Rex" wrote: > Michael D'Errico wrote: >> >> The proposed change (empty extension in both directions on every >> handshake + incorporate previous verify_data into new Finished) has >> some nice benefits over the current RI proposal: > > The are currently TLS servers that will send back unsolicited > TLS extensions to the client if a particular ciphersuite (a real one) > is selected. > > One of the reasons they're doing this is the lack of support for > sending TLS extensions in the ClientHello on WinXP and Win2003 > platforms (for Cryptographic Service Providers). > > It's funny that WinXP/Win2003, although not able or willing to > send TLS extensions in ClientHello, do not seem to barf on > unsolicited ServerHelloExtensions in the server's reply, > and instead make it somehow available for the Cryptographic > Service Provider. > > So for any solution that involves an extension-less C->S > signaling, and a reply in additional data trailing ServerHello, > this data IMHO _needs_ to be a correctly formatted TLS extension, > and the client must be prepared to receive more than one > unsolicited TLS extension as reply and be able to tell them apart. > > > I did complain loudly when first heard their server was sending > unsolicited ServerHelloExtensions when that special cipher suite > was negotiated, but I do have a little empathy for their solution. > At least they correctly wrapped it as a TLS extension and did > not just append arbitrary data to ServerHello. > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Wed Nov 25 10:32:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17F33A687D for ; Wed, 25 Nov 2009 10:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 qpqiheMT3Ddh for ; Wed, 25 Nov 2009 10:32:11 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A1E0F3A68DE for ; Wed, 25 Nov 2009 10:32:10 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPIW39W023647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 19:32:03 +0100 (MET) From: Martin Rex Message-Id: <200911251832.nAPIW2iE012241@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Wed, 25 Nov 2009 19:32:02 +0100 (MET) In-Reply-To: <6b9359640911251020j469c9bb2i4cd12a759e7c5ca2@mail.gmail.com> from "Kyle Hamilton" at Nov 25, 9 10:20:10 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:32:11 -0000 Kyle Hamilton wrote: > > On Tue, Nov 24, 2009 at 4:34 PM, Martin Rex wrote: > > > > Aha. Someone noticed that the S->C signaling is missing. > > > > I suggest using a bit in ServerHello.server_version. > > I don't think that many conforming clients are going to be okay with > that, since they're sending {0x03 0x04}, and you're having the server > send back {0x83 0x04} or {0x03 0x84}. > > The spec of TLS 1.0 implies that the client SHOULD terminate the > connection if it receives back a higher major version number (or minor > version number) than it was expecting. Client conforming to rfc2246, rfc4346 or rfc5246 will not send the magic cipher suite and therefore never get to see this modified server_version. The will also be kicked in a renegotiation handshake. Implementation conforming to the spec that standardizes secure TLS renegotiation will perfectly well understand whatever S->C signal that spec contains. and it will be spec compliant. Spec updates can certainly allow behaviour previously not allowed, but needs provisions not to confuse old implementations. see also http://www.ietf.org/mail-archive/web/tls/current/msg04748.html -Martin From stefan@aaa-sec.com Wed Nov 25 10:34:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80F13A6359 for ; Wed, 25 Nov 2009 10:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKnT7GyyJgQk for ; Wed, 25 Nov 2009 10:34:41 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id D80013A68E7 for ; Wed, 25 Nov 2009 10:34:40 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 390BF28DE93 for ; Wed, 25 Nov 2009 19:34:42 +0100 (CET) Received: (qmail 64120 invoked from network); 25 Nov 2009 18:34:35 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Nov 2009 18:34:35 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 19:34:34 +0100 From: Stefan Santesson To: Stephen Farrell , Message-ID: Thread-Topic: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: Acpt/e8nqJnAv7hlU0WPMnDz3k8IzA== In-Reply-To: <4B0D4BE8.6080605@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:34:41 -0000 Stephen, What you suggest here is not possible following the current proposals. The magic ciphersuite is needed also in the current draft to prevent downgrade attacks. If the signaling is present in one draft, another draft can't change it's meaning. /Stefan On 09-11-25 4:23 PM, "Stephen Farrell" wrote: > I would however support the later publication of > a version of draft-mrex-tls-secure-renegotiation > that only addressed old versions not covered by > draft-ietf-tls-renegotiation. The only reason for > "later" here is that I suspect from the list traffic > that finishing that I-D might take a while. I don't > think draft-ietf-tls-renegotiation should wait on > that. > > If the above turned out to be the plan then I > guess the magic ciphersuite might no longer be > needed in draft-ietf-tls-renegotiation. From marsh@extendedsubset.com Wed Nov 25 10:41:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418D73A6A8A for ; Wed, 25 Nov 2009 10:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 8rHZz2EkS70O for ; Wed, 25 Nov 2009 10:41:04 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 7C9533A68E7 for ; Wed, 25 Nov 2009 10:41:04 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDMnT-000Fe0-A6; Wed, 25 Nov 2009 18:40:59 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F375F603A; Wed, 25 Nov 2009 18:40:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+MyR+J/IbTGInfz3D3WUP0NoInw62qrSU= Message-ID: <4B0D7A36.5070808@extendedsubset.com> Date: Wed, 25 Nov 2009 12:40:54 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911251825.nAPIPamX012002@fs4113.wdf.sap.corp> In-Reply-To: <200911251825.nAPIPamX012002@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:41:05 -0000 Martin Rex wrote: > Marsh Ray wrote: >> Martin Rex wrote: >>> I'm actually very favourable of a restriction that already established >>> identities (not the lack thereof!) must not change during renegotiaton, >>> and contemplating to add this into my proposal as well. >> I believe the current TLS specs do not have a sufficiently rigorous >> definition of "identity" in order to be mandating restrictions like >> this. memcmp() of certs doesn't cut it. At best, they will be ignored. >> At worst, they will entice developers to make unsafe assumptions. > > memcmp() of the certs is the only way TLS can implement this. > This is the only concept of identical known to TLS. It's a pretty weak concept of "identity", too. > Equivalence between different certs (that may even come from > different PKIs) is completely outside of the scope of TLS. > As previous mentioned this is the last paragraph of the > introduction of the TLS spec: > > The TLS standard, however, does not specify how > protocols add security with TLS; the decisions on how to initiate TLS > handshaking and how to interpret the authentication certificates > exchanged are left to the judgment of the designers and implementors > of protocols that run on top of TLS. The spec is saying not to do what you advocate because it's outside the scope of TLS. > Yes, I'm aware that a memcmp() restriction is going to cause > a disruption for Servers that both, actively use renegotiation and > allow server certificates to be updated in-flight. (A lot of servers > require a restart for replacing/updating the server certificate, though). Then please please don't bundle it in with what is supposed to be an urgent bugfix. - Marsh From mrex@sap.com Wed Nov 25 10:52:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4F13A6AFF for ; Wed, 25 Nov 2009 10:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 ghi4jH-iG7+W for ; Wed, 25 Nov 2009 10:52:19 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A4CEC3A6859 for ; Wed, 25 Nov 2009 10:52:18 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAPIqB8q019187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 19:52:11 +0100 (MET) From: Martin Rex Message-Id: <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 25 Nov 2009 19:52:10 +0100 (MET) In-Reply-To: <4B0D7A36.5070808@extendedsubset.com> from "Marsh Ray" at Nov 25, 9 12:40:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:52:19 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > Marsh Ray wrote: > >> Martin Rex wrote: > >>> I'm actually very favourable of a restriction that already established > >>> identities (not the lack thereof!) must not change during renegotiaton, > >>> and contemplating to add this into my proposal as well. > >> I believe the current TLS specs do not have a sufficiently rigorous > >> definition of "identity" in order to be mandating restrictions like > >> this. memcmp() of certs doesn't cut it. At best, they will be ignored. > >> At worst, they will entice developers to make unsafe assumptions. > > > > memcmp() of the certs is the only way TLS can implement this. > > This is the only concept of identical known to TLS. > > It's a pretty weak concept of "identity", too. It is the strongest possible concept of "equivalent identity" in existance. It is also the only one for which I consider a full re-authentication dispensable. Which is what I'm trying to achieve. I would not know how to force a re-authentication onto an existing client app. > > The spec is saying not to do what you advocate because it's outside the > scope of TLS. The spec says that TLS does not include authentication (it often performs certificate path validation, though). > > > Yes, I'm aware that a memcmp() restriction is going to cause > > a disruption for Servers that both, actively use renegotiation and > > allow server certificates to be updated in-flight. (A lot of servers > > require a restart for replacing/updating the server certificate, though). > > Then please please don't bundle it in with what is supposed to be an > urgent bugfix. I think we do have another security problem here that we should fix. There may be a number of apps that simply do not expect that they have to reauthenticate if renegotation allows the identity to change. Could you elaborate on usage scenarios which might be adversly affected by such a requirement/constraint? -Martin From marsh@extendedsubset.com Wed Nov 25 11:17:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4053A6AF0 for ; Wed, 25 Nov 2009 11:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 fu97AoqEkrgU for ; Wed, 25 Nov 2009 11:17:54 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id C6BF03A6847 for ; Wed, 25 Nov 2009 11:17:54 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDNN7-0001st-JV; Wed, 25 Nov 2009 19:17:49 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F363D603A; Wed, 25 Nov 2009 19:17:47 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX185fZ6HGIZL7dEVHrarGT3Up3Bw5IoaIXU= Message-ID: <4B0D82D9.1070609@extendedsubset.com> Date: Wed, 25 Nov 2009 13:17:45 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> In-Reply-To: <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 19:17:55 -0000 Martin Rex wrote: > > It is the strongest possible concept of "equivalent identity" in existance. certificate != identity > It is also the only one for which I consider a full re-authentication > dispensable. > > Which is what I'm trying to achieve. I would not know how to force > a re-authentication onto an existing client app. Most apps shouldn't allow renegotiation at all. The few that do had better know what they're doing. > I think we do have another security problem here that > we should fix. There may be a number of apps that simply do not > expect that they have to reauthenticate if renegotation allows > the identity to change. I agree that there are a lot of apps out there that are not renegotiation-aware. > Could you elaborate on usage scenarios which might be adversly affected > by such a requirement/constraint? No, I don't have to in order to support my argument. In order to support yours though, you need to prove that there are no such apps in existence. TLS is a protocol that operates at certain layers, it provides certain guarantees, and offers certain features. A spec and a version number only have meaning to the extent that the guarantees are properly met and that existing functionality doesn't get yanked out based on the opinions of arbitrary folks on a mailing list like you and me. - Marsh From mrex@sap.com Wed Nov 25 11:53:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7C43A6AFE for ; Wed, 25 Nov 2009 11:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 X-BYT-PsY751 for ; Wed, 25 Nov 2009 11:53:10 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5830B3A694C for ; Wed, 25 Nov 2009 11:53:09 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAPJr2pp008309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 20:53:02 +0100 (MET) From: Martin Rex Message-Id: <200911251952.nAPJquXQ019496@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Wed, 25 Nov 2009 20:52:54 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Nov 25, 9 07:29:51 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 19:53:11 -0000 Stefan Santesson wrote: > > I feel less concerned about having the clients parse an extension. If they > are already capable of handling one additional extension, it should not be > too hard to handle another. > > Especially not if we follow Michael's suggestion and create an empty RI > extension which is easy to add, detect and parse. It makes the interop tests a little more difficult. I don't know how many people do module tests on their code (I know at least one huge software supplier that doesn't). When you _newly_ add a generic parser for TLS extension into a codebase that didn't have it before, and you don't do module tests (=function api-level testing), then you should use several test cases: 1 (unsolicited) TLS extension, (but not RI) 1 (unsolicited) TLS extension, RI 2 (unsolicited) TLS extension, (but not RI) 2 (unsolicited) TLS extensions, RI first 2 (unsolicited) TLS extensions, RI second 3 (unsolicited) TLS extensions, RI second 3 (unsolicited) TLS extensions, RI third which may be something that is difficult to configure with "stock" TLS servers. When you do module/functions tests, then doing the test will be much easier. Just dump test vectors into the spec. :) -Martin From aerowolf@gmail.com Wed Nov 25 11:53:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA293A6B2F for ; Wed, 25 Nov 2009 11:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 evjEEUetL7ok for ; Wed, 25 Nov 2009 11:53:57 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 8E5523A6B21 for ; Wed, 25 Nov 2009 11:53:57 -0800 (PST) Received: by pzk6 with SMTP id 6so27099pzk.29 for ; Wed, 25 Nov 2009 11:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eM2gxtwBsI3oQDt3MEzKkFq6gcK4bgLjZ4lqkmRhXpw=; b=gnH1fStvAcgHzjWjauUD7tyxPMHs+3nIZD34lbQKOT5REF3uVUJVkEWinFvJww4iu4 IpxPx7T3muSnrF8Z80IjdQSkfoc/9k6nDcvCAhgpc4kRAr0bdPoly/nexcss8DA2O86C dab+Vezebr96IcC+JAKiTST5jTiQLEaQcZVv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=m8YLHSeCFOzl2X8uNQmeVDpeM8XEzc4iRm/OlvM9x8clzJpus5Cd1H/Xh0ucY74SjL YzzzEEXTl2jAQdu5LiRs+EXzBD9GzZT4QZX5vt7NO1FYumNyYcL0CH1PzJOCocTsYStu 51/C0QLaJNrFfb3x4N0bO2Lac40CgSEjoF9JU= MIME-Version: 1.0 Received: by 10.142.248.42 with SMTP id v42mr957861wfh.187.1259178829975; Wed, 25 Nov 2009 11:53:49 -0800 (PST) In-Reply-To: <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> References: <4B0D7A36.5070808@extendedsubset.com> <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> Date: Wed, 25 Nov 2009 11:53:49 -0800 Message-ID: <6b9359640911251153o338f5175m78a20d62e449c7cc@mail.gmail.com> From: Kyle Hamilton To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 19:53:58 -0000 Do *not* put any arbitrary policy decisions into an IETF standard. Such as "must not change Identity". I can see *several* situations where an identity could be usefully changed inside a connection -- for example, a manager putting in her smart card (on the same machine as the worker) and keying in her pin, to be prompted by the server to authorize a given transaction -- and then pulling the smart card out again, thus removing the capability to use that key. (This is the kind of thing that is done at, for example, Fry's Electronics... except that they just use usernames and passwords to authenticate and authorize.) Another is the case where a given identity is unacceptable for some operation -- for example, I end up using my kyanhaATkyanhaDOTnet certificate to try to do something that only aerowolf@gmail.com is allowed to do. I'd prefer to keep the same TLS connection, just change the identity that it's bound to. (What about the situation where your cert has been revoked and OCSP is saying that it is, and you're trying to put a replacement into place? Or, if the root you've been using has been dropped from the Trust List of whatever browser your clients are using -- you're suddenly untrusted. So you need to get a completely different signer -- and that will completely fail the memcmp test. It might even fail strcmp on the components of the Subject. Regardless, this is outside the scope of TLS; it is the application designer and the application consumer who determine the security policy that they're going to use, not any one of us.) -Kyle H On Wed, Nov 25, 2009 at 10:52 AM, Martin Rex wrote: > Marsh Ray wrote: >> >> Martin Rex wrote: >> > Marsh Ray wrote: >> >> Martin Rex wrote: >> >>> I'm actually very favourable of a restriction that already establish= ed >> >>> identities (not the lack thereof!) must not change during renegotiat= on, >> >>> and contemplating to add this into my proposal as well. >> >> I believe the current TLS specs do not have a sufficiently rigorous >> >> definition of "identity" in order to be mandating restrictions like >> >> this. memcmp() of certs doesn't cut it. At best, they will be ignored= . >> >> At worst, they will entice developers to make unsafe assumptions. >> > >> > memcmp() of the certs is the only way TLS can implement this. >> > This is the only concept of identical known to TLS. >> >> It's a pretty weak concept of "identity", too. > > It is the strongest possible concept of "equivalent identity" in existanc= e. > > It is also the only one for which I consider a full re-authentication > dispensable. > > Which is what I'm trying to achieve. =C2=A0I would not know how to force > a re-authentication onto an existing client app. > > >> >> The spec is saying not to do what you advocate because it's outside the >> scope of TLS. > > The spec says that TLS does not include authentication > (it often performs certificate path validation, though). > >> >> > Yes, I'm aware that a memcmp() restriction is going to cause >> > a disruption for Servers that both, actively use renegotiation and >> > allow server certificates to be updated in-flight. (A lot of servers >> > require a restart for replacing/updating the server certificate, thoug= h). >> >> Then please please don't bundle it in with what is supposed to be an >> urgent bugfix. > > I think we do have another security problem here that > we should fix. =C2=A0There may be a number of apps that simply do not > expect that they have to reauthenticate if renegotation allows > the identity to change. > > Could you elaborate on usage scenarios which might be adversly affected > by such a requirement/constraint? > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From aerowolf@gmail.com Wed Nov 25 12:00:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E963A6B5D for ; Wed, 25 Nov 2009 12:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 lXv1DbgLq8rx for ; Wed, 25 Nov 2009 12:00:18 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id E16313A6BA0 for ; Wed, 25 Nov 2009 12:00:11 -0800 (PST) Received: by pxi16 with SMTP id 16so30119pxi.29 for ; Wed, 25 Nov 2009 12:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mhaQmpYHeDt3a5n3I9GQebQMFEESDuCjDw0VdDOxQZI=; b=GBvPYCBU+vK5aJs/Mcvu6gcgQ97O6LVf2N5eX/3L4zwFH4AF0Yb1dLbrYEiKj15Ml6 hrktfFA0MieSUR/cd/SFRaoBE4EF2kUbprdt+EH0JZNUJ4EI0WYiY+TQDcwMrlyEIUn7 Krn/aSLDQfoo6lX/KtaxOAVvrpQT38st2Yg0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bWYLjlNpuGlykCb34DPQsl1OOGAf9UP6TRJ1urUvYAXhconPeylGl6XGRd4elbsCTQ L5fB0m+IAMLB8a+CsG28N4IjS1Q+9GGLkVfiGZB2gsQBhKcRFpeyQlgvUguVEAID8V3M ABzQankyXiyefQoLo391VD97lfFjMoxDmHrQ0= MIME-Version: 1.0 Received: by 10.143.24.42 with SMTP id b42mr864684wfj.41.1259179203904; Wed, 25 Nov 2009 12:00:03 -0800 (PST) In-Reply-To: <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> References: <4B0D7A36.5070808@extendedsubset.com> <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> Date: Wed, 25 Nov 2009 12:00:03 -0800 Message-ID: <6b9359640911251200g1628e16el5c2fe3e3f373f8fd@mail.gmail.com> From: Kyle Hamilton To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:00:19 -0000 TLS does not mandate authentication, and thus does not mandate any specific Identity. The only case where it mandates authentication is when the Server wishes to ask the Client for its identity, and that's arguably a policy decision which, since it's in the spec, is a bug. (I can see HTTP servers not being able to, but as an underlying protocol TLS shouldn't cater to the wants of specific protocols and protocol usages.) TLS also does not specify certificate path validation -- that is the function of PKIX, currently RFC 5280. It just happens that because ASN.1 DER and BER aren't common in the internet world, the only things that can really parse it are special-purpose certificate verifiers, and those are special-purpose enough that they get bundled with most TLS implementations. However, separate libraries for validating certificates do exist. http://libpkix.sourceforge.net/ is one that is open-source. Certificate path validation is not inherently tied to TLS -- just think of S/MIME, hmm? -Kyle H On Wed, Nov 25, 2009 at 10:52 AM, Martin Rex wrote: > Marsh Ray wrote: >> >> Martin Rex wrote: >> > Marsh Ray wrote: >> >> Martin Rex wrote: >> >>> I'm actually very favourable of a restriction that already establish= ed >> >>> identities (not the lack thereof!) must not change during renegotiat= on, >> >>> and contemplating to add this into my proposal as well. >> >> I believe the current TLS specs do not have a sufficiently rigorous >> >> definition of "identity" in order to be mandating restrictions like >> >> this. memcmp() of certs doesn't cut it. At best, they will be ignored= . >> >> At worst, they will entice developers to make unsafe assumptions. >> > >> > memcmp() of the certs is the only way TLS can implement this. >> > This is the only concept of identical known to TLS. >> >> It's a pretty weak concept of "identity", too. > > It is the strongest possible concept of "equivalent identity" in existanc= e. > > It is also the only one for which I consider a full re-authentication > dispensable. > > Which is what I'm trying to achieve. =C2=A0I would not know how to force > a re-authentication onto an existing client app. > > >> >> The spec is saying not to do what you advocate because it's outside the >> scope of TLS. > > The spec says that TLS does not include authentication > (it often performs certificate path validation, though). > >> >> > Yes, I'm aware that a memcmp() restriction is going to cause >> > a disruption for Servers that both, actively use renegotiation and >> > allow server certificates to be updated in-flight. (A lot of servers >> > require a restart for replacing/updating the server certificate, thoug= h). >> >> Then please please don't bundle it in with what is supposed to be an >> urgent bugfix. > > I think we do have another security problem here that > we should fix. =C2=A0There may be a number of apps that simply do not > expect that they have to reauthenticate if renegotation allows > the identity to change. > > Could you elaborate on usage scenarios which might be adversly affected > by such a requirement/constraint? > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Pasi.Eronen@nokia.com Wed Nov 25 12:03:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B763A6945 for ; Wed, 25 Nov 2009 12:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 Ow8gEoKXBMh2 for ; Wed, 25 Nov 2009 12:03:09 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 134E33A6820 for ; Wed, 25 Nov 2009 12:03:08 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPK2vF6030552; Wed, 25 Nov 2009 22:02:58 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 22:02:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 22:02:57 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 25 Nov 2009 21:02:56 +0100 From: To: , Date: Wed, 25 Nov 2009 21:02:55 +0100 Thread-Topic: [TLS] some questions for your draft Thread-Index: Acpt8AnrKXrMGHA1TWCYC5xX6NV2AwAGKg+Q Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE976@NOK-EUMSG-01.mgdnok.nokia.com> References: <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com> <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> <4B0D5EF3.3020905@extendedsubset.com> <20091125165522.A2CDA6C3173@kilo.networkresonance.com> In-Reply-To: <20091125165522.A2CDA6C3173@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 20:02:57.0551 (UTC) FILETIME=[485181F0:01CA6E0A] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:03:10 -0000 Eric Rescorla wrote: > As I said, Pasi Eronen suggested it and it seemed sound to me. >=20 > I'm not wedded to it and if the WG feels that it's a bad idea, I'll > gladly take it out. Pasi? IMHO the recent discussions seem to indicate that many applications would be confused (in ways that could lead to security problems) by identity changes during renegotiation, because the TLS library APIs usually try to hide renegotiation from applications. While the RI extension fixes the man-in-the-middle problem, it doesn't remove the problems when there is no man-in-the-middle, just the two endpoints (either of whom could be potentially malicious). So IMHO this draft needs either Security Considerations text explaining "even when the RI extension is used, renegotiation is quite likely to do things you wouldn't expect and possibly break your security", or make the default behavior much less surprising. I would prefer the latter.=20 For the TLS library, the only form of identity comparison it can do is memcmp(), since all the rest depends on what semantics the applications give to various fields in the certificate (subject, subjectAltName, NameConstraints, Clearance, CertificatePolicies, etc.). But if the application wants to do more complex identity comparison, it can do so. (And the current text intentionally allows moving from e.g. DH-anon or server-only auth to mutual auth with certs.) Best regards, Pasi From Pasi.Eronen@nokia.com Wed Nov 25 12:05:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1C33A6B1A for ; Wed, 25 Nov 2009 12:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 AbtrT4eUtyWD for ; Wed, 25 Nov 2009 12:05:58 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 99AA53A6B41 for ; Wed, 25 Nov 2009 12:05:57 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAPK5k7A021523; Wed, 25 Nov 2009 22:05:48 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 22:05:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 22:05:42 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 25 Nov 2009 21:05:40 +0100 From: To: , , Date: Wed, 25 Nov 2009 21:05:39 +0100 Thread-Topic: [TLS] some questions for your draft Thread-Index: AQHKbaw1gs9E5dgW2EGnpw7vVM9jX5FHh+eAgAADAwD//4CIMIAALdUw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310FE97C@NOK-EUMSG-01.mgdnok.nokia.com> References: <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com> <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> <4B0D5EF3.3020905@extendedsubset.com> <20091125165522.A2CDA6C3173@kilo.networkresonance.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2009 20:05:42.0761 (UTC) FILETIME=[AACA8D90:01CA6E0A] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:05:58 -0000 Nasko Oskov wrote: > Someone already mentioned load balancers that change certs on > renegotiation. At the very least this could be a SHOULD instead of > MUST. Yngve's email was about a load balancer directing different TCP connections to different physical servers (with different certs), which would mean different HTTP requests for the same page could end up in different servers. But renegotiation is not going to move your TLS connection from one physical box to another, so there the cert would remain same. (And note the requirement is qualified by "unless the application explicitly asks to allow identity changes") > The way I read it, it prevents the current client auth implementations, > since it disallows change of identity (from anon to authenticated). The intention was to allow changing from anon to authenticated, but perhaps the wording isn't as clear as it should be. Best regards, Pasi From mrex@sap.com Wed Nov 25 12:28:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDAC3A6B4D for ; Wed, 25 Nov 2009 12:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 GZ3D1LYwoZEN for ; Wed, 25 Nov 2009 12:28:40 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A05483A6B50 for ; Wed, 25 Nov 2009 12:28:39 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAPKSUTl010053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 21:28:30 +0100 (MET) From: Martin Rex Message-Id: <200911252028.nAPKSRB0022007@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Wed, 25 Nov 2009 21:28:26 +0100 (MET) In-Reply-To: <6b9359640911251153o338f5175m78a20d62e449c7cc@mail.gmail.com> from "Kyle Hamilton" at Nov 25, 9 11:53:49 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:28:41 -0000 Kyle Hamilton wrote: > > Do *not* put any arbitrary policy decisions into an IETF standard. > Such as "must not change Identity". You put it _much_ more generic that it is being discussed. > > I can see *several* situations where an identity could be usefully > changed inside a connection -- for example, a manager putting in her > smart card (on the same machine as the worker) and keying in her pin, > to be prompted by the server to authorize a given transaction -- and > then pulling the smart card out again, thus removing the capability to > use that key. (This is the kind of thing that is done at, for > example, Fry's Electronics... except that they just use usernames and > passwords to authenticate and authorize.) I don't see why this is a renegotiation scenario. And it seems that your area of application does perform a re-authentication at the app-level (and looks like a change in client-identity, not a server-identity), so it doesn't apply to the scenario that I want to get fixed. Your help in wiggling out the details of the final constraint is still welcome. I would want such a constraint to be as clear as we can make it in order to not break existing usage scenarios and possible future applications of the TLS technology. -Martin From mrex@sap.com Wed Nov 25 12:33:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0E93A6926 for ; Wed, 25 Nov 2009 12:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.084, 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 3yBQYlnL7vPB for ; Wed, 25 Nov 2009 12:33:49 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A744A3A6837 for ; Wed, 25 Nov 2009 12:33:48 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAPKXew6014023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 21:33:40 +0100 (MET) From: Martin Rex Message-Id: <200911252033.nAPKXc8U022186@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Wed, 25 Nov 2009 21:33:37 +0100 (MET) In-Reply-To: <6b9359640911251200g1628e16el5c2fe3e3f373f8fd@mail.gmail.com> from "Kyle Hamilton" at Nov 25, 9 12:00:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:33:49 -0000 Kyle Hamilton wrote: > > TLS also does not specify certificate path validation -- that is the > function of PKIX, currently RFC 5280. It just happens that because > ASN.1 DER and BER aren't common in the internet world, the only things > that can really parse it are special-purpose certificate verifiers, > and those are special-purpose enough that they get bundled with most > TLS implementations. That is not fully correct. If you read through the description of the Server Certificate message in the TLS spec, that does create a certain level of expectations what a TLS implementation should do with regards to Server Certificate Validation. -Martin From ietf-ietf-tls@m.gmane.org Wed Nov 25 12:39:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAC93A6B53 for ; Wed, 25 Nov 2009 12:39:55 -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 MQ51mNhnfP27 for ; Wed, 25 Nov 2009 12:39:54 -0800 (PST) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id 841B83A6B58 for ; Wed, 25 Nov 2009 12:39:54 -0800 (PST) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NDOeS-0000fY-FD for tls@ietf.org; Wed, 25 Nov 2009 21:39:48 +0100 Received: from rain.gmane.org ([80.91.229.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Nov 2009 21:39:48 +0100 Received: from Bruno.Harbulot by rain.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Nov 2009 21:39:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Bruno Harbulot Date: Wed, 25 Nov 2009 20:39:24 +0000 Lines: 43 Message-ID: References: <200911251724.nAPHOMf2007151@fs4113.wdf.sap.corp> <4B0D6A7B.1040803@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: rain.gmane.org User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) In-Reply-To: <4B0D6A7B.1040803@extendedsubset.com> Sender: news Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:39:55 -0000 Hello, Marsh Ray wrote: > Martin Rex wrote: >> I'm actually very favourable of a restriction that already established >> identities (not the lack thereof!) must not change during renegotiaton, >> and contemplating to add this into my proposal as well. > > I believe the current TLS specs do not have a sufficiently rigorous > definition of "identity" in order to be mandating restrictions like > this. memcmp() of certs doesn't cut it. At best, they will be ignored. > At worst, they will entice developers to make unsafe assumptions. (Apologies for jumping in this discussion, I have only been able to read some of the e-mails posted on this list this month.) I think the TLS spec should stay away from the concept of identity. This is too vague a concept and people have different expectations for it. It's more appropriate in something like PKIX. Some certificate-based mechanisms do not necessarily rely on the concept of user identity (in the sense of certificate = user). One could imagine a situation where a client would initially present a client certificate that contains attributes (like an attribute certificate), but that doesn't embed the attributes the server wants for this particular request. The server could then initiate a re-negotiation to ask the client to present another certificate, with other attributes. This can be particularly useful for role-based (or virtual organisation) authorisation, for example. The concept of identity then becomes rather loose; in some contexts, anonymity might even be required. I don't think that TLS should address this; rather, it should be up to the components that verify the certificates. Best wishes, Bruno. From mike-list@pobox.com Wed Nov 25 13:02:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5071F3A6820 for ; Wed, 25 Nov 2009 13:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 HcWW7JdgHT3A for ; Wed, 25 Nov 2009 13:02:04 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 6BAAC3A67A1 for ; Wed, 25 Nov 2009 13:02:04 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5CD94A184F for ; Wed, 25 Nov 2009 16:01:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=oO8Yug9AVw31t/XoCPxJlYlVA Ls=; b=HMKCD1izV5jvuYyrUkh2wdKtBx/xI6Lp0bXHjN2Nj6+9rj2A18kML7PzD WNhQ6TuBiwWtwqoa1aa3sfL4QBHMP04GRHWP25txPMKioCg0Cv3KazkQqIxOITT6 VxUrJtMbBfsXbjhLQxpw2SY7W3iBN1tPgeFiGOJMr9oh62fay0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=QG0SweIJ4Enof3ZKRnU hEqmxQZTQEvB/O09idBHASp9/eL41NAqg5K8BpmB/F34Jep4qctQB7XsYCDeChzj cm1wDPcnmlrxDeFkQFh9tauCISVqu7E3qCxvktU/6ABBQtq+fIxdCQYeun9aow30 rWdUuY76fgTxlLAlH9HK1kI4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5A416A184E for ; Wed, 25 Nov 2009 16:01:59 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id C27FDA184D for ; Wed, 25 Nov 2009 16:01:58 -0500 (EST) Message-ID: <4B0D9B94.9080205@pobox.com> Date: Wed, 25 Nov 2009 13:03:16 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: C5A43974-DA05-11DE-9383-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:02:05 -0000 I think that it would be good to find a unified solution that everybody is happy with, and believe that this may be it: 1) Client-to-Server signalling can be done in either of two ways: A) an empty Secure_Renegotiation (SR) extension, or B) a "magic" cipher suite 2) Server-to-Client signal is always an empty SR extension 3) Incorporate previous verify_data into Finished calc. The particulars: A client that currently sends any other extensions MUST also send the empty SR extension. A client that currently does not send any extensions MAY send the empty SR extension, or MAY send the magic cipher suite. In response to either 1A or 1B, the server responds with an empty SR extension. The only ugliness is this apparently- unsolicited extension returned by the server in response to the magic cipher suite. I used to be against this, but have since decided that it is no more ugly than flipping a version bit or any of the other ideas. It remains to be decided if adding the verify_data to the handshake message stream is the right way to do (3), or if changing the PRF in some way is better, such as changing the seed to be the handshake message hash appended with the old verify_data, or some other method. Benefits: All versions including SSLv3 are fixed and able to renegotiate safely. This is entirely backward-compatible with SSLv3, even SSLv2 ClientHello. It is better than RI because when the magic cipher suite is used there, the server can not check the verify_data from the client (since it is not sent), so it can not renegotiate with those old clients at all. Using an empty extension is much more lightweight a use of extensions than RI since there is no need to pack the verify_ data into it when sending, or to extract the data when receiving. Clients that don't want to add full support for extensions do not need to -- they can just check for the existence of the empty SR extension which is a fixed 6-byte string. I would fully support this "new"[*] solution. Anybody else? Mike [*] I do not remember who initially came up with each of the ideas in this solution; it was truly a team effort. From marsh@extendedsubset.com Wed Nov 25 13:37:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D5D3A6950 for ; Wed, 25 Nov 2009 13:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO5483zq7JC7 for ; Wed, 25 Nov 2009 13:37:45 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id D4C563A6921 for ; Wed, 25 Nov 2009 13:37:45 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDPYS-000MgO-Ia; Wed, 25 Nov 2009 21:37:40 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 84387603A; Wed, 25 Nov 2009 21:37:39 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18FuCRaOlKdSi+9TJBTDo7fyEalpfGTPfM= Message-ID: <4B0DA3A0.5000805@extendedsubset.com> Date: Wed, 25 Nov 2009 15:37:36 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <4B0D9B94.9080205@pobox.com> In-Reply-To: <4B0D9B94.9080205@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: TLS Working Group Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:37:46 -0000 Michael D'Errico wrote: > I think that it would be good to find a unified solution that > everybody is happy with, and believe that this may be it: > > 1) Client-to-Server signalling can be done in either of > two ways: > > A) an empty Secure_Renegotiation (SR) extension, or > B) a "magic" cipher suite > > 2) Server-to-Client signal is always an empty SR extension > > 3) Incorporate previous verify_data into Finished calc. I like it! > The particulars: > > A client that currently sends any other extensions MUST also > send the empty SR extension. Is the server's behavior defined if he does not? E.g. alert message, terminate, format C: /y, etc. Wouldn't a robust implementation have to look out for that condition anyway? Does this requirement amount to "this will never happen so you don't have to bother testing for it (until your product hits the net)"? > A client that currently does not send any extensions MAY send > the empty SR extension, or MAY send the magic cipher suite. Can he send both (is the 'or' inclusive)? What happens when the server receives both? Can a patched client send neither? > In response to either 1A or 1B, the server responds with an > empty SR extension. The (patched) server MUST respond with ... If the server does not respond with the extension the client MAY, depending on external configuration, elect to continue the handshake insecurely, or alert+abort (specifics). The client SHOULD check that the extension_data is in fact empty (i.e., just its two length bytes of 00 00), and alert+aborting if not. > The only ugliness is this apparently- > unsolicited extension returned by the server in response to > the magic cipher suite. I used to be against this, but have > since decided that it is no more ugly than flipping a version > bit or any of the other ideas. RFC 4346 (TLS 1.1) (and earlier versions) http://tools.ietf.org/html/rfc4346#section-7.4.1.3 says Server Hello doesn't have extensions at all, yet it is updated by RFC 4366 which adds them. What we are doing is no different AFAICT. > It remains to be decided if adding the verify_data to the > handshake message stream is the right way to do (3), or if > changing the PRF in some way is better, such as changing the > seed to be the handshake message hash appended with the old > verify_data, or some other method. I think most people are comfortable with that approach. Suggestions: This extension applies equally to ALL handshakes on a single connection regardless of whether they are an initial handshake or a renegotiation. Client and server MUST negotiate the use of SR in the same manner (including the choice of magic ciphersuite or Client Hello extension) for all handshakes on a single connection. Clients and servers SHOULD detect the case where the other party has inconsistently negotiated the use of (or not using) SR and immediately discard buffered data and alert+abort. > Benefits: > > All versions including SSLv3 are fixed and able to renegotiate > safely. Hooray! > This is entirely backward-compatible with SSLv3, even SSLv2 > ClientHello. It is better than RI because when the magic > cipher suite is used there, the server can not check the > verify_data from the client (since it is not sent), so it > can not renegotiate with those old clients at all. Yippee! > Using an empty extension is much more lightweight a use of > extensions than RI since there is no need to pack the verify_ > data into it when sending, or to extract the data when > receiving. It saves 24 bytes in each direction! > Clients that don't want to add full support for extensions do > not need to -- they can just check for the existence of the > empty SR extension which is a fixed 6-byte string. Hard for anyone to complain about that, considering nobody was really happy with the alternatives. > I would fully support this "new"[*] solution. Anybody else? I support the solution! Can we get the "bits on the wire" part drafted without unnecessary other baggage? - Marsh From mrex@sap.com Wed Nov 25 14:06:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235323A6B89 for ; Wed, 25 Nov 2009 14:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 X3kHpmKMMOhN for ; Wed, 25 Nov 2009 14:06:04 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 09C513A6B45 for ; Wed, 25 Nov 2009 14:06:03 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPM5v4c020439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 23:05:57 +0100 (MET) From: Martin Rex Message-Id: <200911252205.nAPM5uCQ027921@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 25 Nov 2009 23:05:56 +0100 (MET) In-Reply-To: <4B0D9B94.9080205@pobox.com> from "Michael D'Errico" at Nov 25, 9 01:03:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:06:05 -0000 Michael D'Errico wrote: > > I think that it would be good to find a unified solution that > everybody is happy with, and believe that this may be it: > > > 1) Client-to-Server signalling can be done in either of > two ways: > > A) an empty Secure_Renegotiation (SR) extension, or > B) a "magic" cipher suite > > 2) Server-to-Client signal is always an empty SR extension > > 3) Incorporate previous verify_data into Finished calc. > > > The particulars: > > A client that currently sends any other extensions MUST also > send the empty SR extension. > > A client that currently does not send any extensions MAY send > the empty SR extension, or MAY send the magic cipher suite. A client MUST send the magic cipher suite. A client that sends any TLS extension SHOULD send the the emtpy SR extension as well. The server MUST check for the presence of the magic ciphersuite and MUST use secure renegotiation when present. The server SHOULD NOT complain of absence of SR extension when the magic ciphersuite is present. -Martin From nelson@bolyard.me Wed Nov 25 14:21:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6173A6B61 for ; Wed, 25 Nov 2009 14:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 P1W9cq+g6QGk for ; Wed, 25 Nov 2009 14:21:08 -0800 (PST) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id C61083A6774 for ; Wed, 25 Nov 2009 14:21:08 -0800 (PST) Received: (qmail 3057 invoked from network); 25 Nov 2009 22:21:02 -0000 Received: from unknown (24.5.142.42) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 25 Nov 2009 22:21:01 -0000 Message-ID: <4B0DAE38.8030206@bolyard.me> Date: Wed, 25 Nov 2009 14:22:48 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:21:09 -0000 On 2009-11-25 01:39 PST, Yoav Nir wrote: > On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote: > >> So how would this work as a middle way between the proposals: >> >> C->S Signaling: >> 1) Client MUST include either the magic CipherSuite or RI extension or both >> 2a) TLS compatible server MUST support magic CipherSuite and RI. >> 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI > > How about: > 2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI > 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support RI Why would you separate TLS 1.0 servers from TLS 1.1+ ? From stefan@aaa-sec.com Wed Nov 25 14:30:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850CE3A6852 for ; Wed, 25 Nov 2009 14:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z5LsuTVh55y for ; Wed, 25 Nov 2009 14:30:58 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 63F913A67AA for ; Wed, 25 Nov 2009 14:30:57 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 11A0D28F8F7 for ; Wed, 25 Nov 2009 23:31:00 +0100 (CET) Received: (qmail 28284 invoked from network); 25 Nov 2009 22:30:51 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Nov 2009 22:30:51 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 23:30:48 +0100 From: Stefan Santesson To: , Michael D'Errico Message-ID: Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: AcpuHu+EIo/RBEPfxE66m0IwPynuuQ== In-Reply-To: <200911252205.nAPM5uCQ027921@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:30:59 -0000 I support this. I'm not sure whether the "magic" cipher suite MUST be present. I think both approaches are acceptable but it feels like having it always present may however offer better consistency after all and lead to simpler test cases. /Stefan On 09-11-25 11:05 PM, "Martin Rex" wrote: > Michael D'Errico wrote: >> >> I think that it would be good to find a unified solution that >> everybody is happy with, and believe that this may be it: >> >> >> 1) Client-to-Server signalling can be done in either of >> two ways: >> >> A) an empty Secure_Renegotiation (SR) extension, or >> B) a "magic" cipher suite >> >> 2) Server-to-Client signal is always an empty SR extension >> >> 3) Incorporate previous verify_data into Finished calc. >> >> >> The particulars: >> >> A client that currently sends any other extensions MUST also >> send the empty SR extension. >> >> A client that currently does not send any extensions MAY send >> the empty SR extension, or MAY send the magic cipher suite. > > > A client MUST send the magic cipher suite. A client that sends > any TLS extension SHOULD send the the emtpy SR extension as well. > > The server MUST check for the presence of the magic ciphersuite > and MUST use secure renegotiation when present. The server > SHOULD NOT complain of absence of SR extension when the > magic ciphersuite is present. > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ekr@networkresonance.com Wed Nov 25 14:34:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123923A67AE for ; Wed, 25 Nov 2009 14:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.328 X-Spam-Level: X-Spam-Status: No, score=0.328 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arE1nI0A5ZI3 for ; Wed, 25 Nov 2009 14:34:32 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 2BBED3A67AA for ; Wed, 25 Nov 2009 14:34:32 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 4265B6C3285 for ; Wed, 25 Nov 2009 14:35:02 -0800 (PST) Date: Wed, 25 Nov 2009 14:35:02 -0800 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091125223502.4265B6C3285@kilo.networkresonance.com> Subject: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:34:33 -0000 Folks, I wanted to try to resolve what I see as the major technical concern people have about draft-ietf-tls-renegotiation-00, namely that the client cannot offer secure renegotiation and be sure that it won't cause a connection failure with a downrev (extension noncompliant) server. There's been a lot of discussion of whether this is a serious problem, but it's clear that minimal risk of breaking things that currently work (which some folks think requires not using extensions in the initial ClientHello) is important for the timely deployment of the fix, and with the current draft, that may require fall-back to extension-less handshake. It's unclear how often such fall-back logic would actually be needed, and I do find Nelson's "tough love" approach here sort of appealing, but it does seem to be a problem that you don't necessarily know for sure whether you need it or not until you've actually shipped the product with extensions, and possibly broken applications that currently work. It's especially concerning that fall-back can't be implemented reliably inside the TLS library, e.g., if you just get a filehandle, so changes to the app logic are required. The rest of this message describes a simple modification [*] to draft-ietf-tls-negotiation which I think addresses this compatibility issue without requiring fall-back. The idea is to use a magic cipher suite to signal that the client can securely renegotiate (as described in draft-mrex-tls-secure-renegotiation). However, the server treats this EXACTLY as if the client had offered an empty RI extension, and responds with its own RI extension (or if it doesn't implement the full extension framework, just adds a known byte string to the end of the ServerHello). In other words: Client Server ------------------------------------------------------ ClientHello + TLS_RENEGO_PROTECTION_REQUEST -> <- ServerHello + Empty RI At this point, the client now knows that the server supports secure renegotiation and can simply send RI in any renegotiation handshake (and if the client doesn't implement the full extensions framework, it could just add a known byte string to the end of the ClientHello, without requiring full extension support). Note that this is reminiscent of the SSLv2->SSLv3 transition where clients would initially offer backward compatibility handshakes but once they knew the server was SSLv3-capable would offer the new ClientHello. What about 5246 and unsolicited extensions? As far as I can tell, the major argument against using extensions for S->C signalling is the 5246 prohibition against the server providing unsolicited extensions. However, that was clearly intended to prevent the server from sending extensions the client didn't expect and that's not the case here. Moreover, we're updating 5246 so we can relax the restriction for this extension (though I would think not in general). What about not putting the verify data in the extension? I think that issue is separable from the question of how we signal support, so would like to deal with it separately. (It seems this won't make any difference for the bigger questions like can deploying the fix break things that currently work, or whether you can implement the fix purely inside the TLS library) What about SSLv3? Obviously, the ClientHello is compatible with SSLv3. (and the magic cipher suite can be offered even in SSLv2 backward compatible hello---ugh!). Although SSLv3 does not have the TLS extension framework, we could also specify that the server (once it sees the magic cipher suite indicating the client supports this draft) just appends the relevant fixed-length byte string to the end of the ServerHello. What do people think about this approach? -Ekr [*] I didn't invent this approach, I'm just reproposing it to try to focus discussion. From mrex@sap.com Wed Nov 25 14:34:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF023A6B52 for ; Wed, 25 Nov 2009 14:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, 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 QlWC6bI7fo3h for ; Wed, 25 Nov 2009 14:34:46 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id AEF4D3A68CF for ; Wed, 25 Nov 2009 14:34:45 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPMYau2016288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 23:34:36 +0100 (MET) From: Martin Rex Message-Id: <200911252234.nAPMYZAx029809@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Wed, 25 Nov 2009 23:34:34 +0100 (MET) In-Reply-To: <4B0DAE38.8030206@bolyard.me> from "Nelson B Bolyard" at Nov 25, 9 02:22:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:34:46 -0000 Nelson B Bolyard wrote: > > On 2009-11-25 01:39 PST, Yoav Nir wrote: > > On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote: > > > >> So how would this work as a middle way between the proposals: > >> > >> C->S Signaling: > >> 1) Client MUST include either the magic CipherSuite or RI extension or both > >> 2a) TLS compatible server MUST support magic CipherSuite and RI. > >> 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI > > > > How about: > > 2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI > > 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support RI > > Why would you separate TLS 1.0 servers from TLS 1.1+ ? Maybe because a large number of TLS 1.0 servers do not support TLS extensions (rightly so), they're just extensions-tolerant. -Martin From stefan@aaa-sec.com Wed Nov 25 14:34:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527553A6B73 for ; Wed, 25 Nov 2009 14:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e58DT2d4DEXR for ; Wed, 25 Nov 2009 14:34:56 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 85FA33A6B6E for ; Wed, 25 Nov 2009 14:34:56 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id EDE9228E9C0 for ; Wed, 25 Nov 2009 23:34:59 +0100 (CET) Received: (qmail 6462 invoked from network); 25 Nov 2009 22:34:51 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Nov 2009 22:34:51 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 23:34:50 +0100 From: Stefan Santesson To: Nelson B Bolyard , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] Other S->C signaling methods Thread-Index: AcpuH3/C4eKlVCQQoEydizzmnjjdBQ== In-Reply-To: <4B0DAE38.8030206@bolyard.me> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:34:57 -0000 I think the rule set posted by Michael is better. The client may not know what version of TLS the server will choose when sending it's hello, so a generic rule of C->S signaling seems more appropriate. /Stefan On 09-11-25 11:22 PM, "Nelson B Bolyard" wrote: > On 2009-11-25 01:39 PST, Yoav Nir wrote: >> On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote: >> >>> So how would this work as a middle way between the proposals: >>> >>> C->S Signaling: >>> 1) Client MUST include either the magic CipherSuite or RI extension or both >>> 2a) TLS compatible server MUST support magic CipherSuite and RI. >>> 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI >> >> How about: >> 2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI >> 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support >> RI > > Why would you separate TLS 1.0 servers from TLS 1.1+ ? > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Wed Nov 25 14:44:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407743A67C2 for ; Wed, 25 Nov 2009 14:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3ajGZb1g8zw for ; Wed, 25 Nov 2009 14:44:42 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id F22913A6405 for ; Wed, 25 Nov 2009 14:44:41 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 79C5328E7D4 for ; Wed, 25 Nov 2009 23:44:44 +0100 (CET) Received: (qmail 68557 invoked from network); 25 Nov 2009 22:44:35 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Nov 2009 22:44:35 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 23:44:33 +0100 From: Stefan Santesson To: Eric Rescorla , Message-ID: Thread-Topic: [TLS] Avoiding first use of RI in ClientHello Thread-Index: AcpuINtBpqAg/HDjo0+kMje6+cDs7w== In-Reply-To: <20091125223502.4265B6C3285@kilo.networkresonance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:44:43 -0000 Eric, I think this is a great approach and in line with recent proposals. I prefer the RI extension without the verify data for reasons previously stated on the list. /Stefan On 09-11-25 11:35 PM, "Eric Rescorla" wrote: > Folks, > > I wanted to try to resolve what I see as the major technical concern > people have about draft-ietf-tls-renegotiation-00, namely that the > client cannot offer secure renegotiation and be sure that it won't > cause a connection failure with a downrev (extension noncompliant) > server. > > There's been a lot of discussion of whether this is a serious problem, > but it's clear that minimal risk of breaking things that currently > work (which some folks think requires not using extensions in the > initial ClientHello) is important for the timely deployment of the > fix, and with the current draft, that may require fall-back to > extension-less handshake. > > It's unclear how often such fall-back logic would actually be needed, > and I do find Nelson's "tough love" approach here sort of appealing, > but it does seem to be a problem that you don't necessarily know for sure > whether you need it or not until you've actually shipped the product > with extensions, and possibly broken applications that currently work. > It's especially concerning that fall-back can't be implemented reliably > inside the TLS library, e.g., if you just get a filehandle, so changes > to the app logic are required. > > > The rest of this message describes a simple modification [*] to > draft-ietf-tls-negotiation which I think addresses this compatibility > issue without requiring fall-back. > > The idea is to use a magic cipher suite to signal that the client can > securely renegotiate (as described in > draft-mrex-tls-secure-renegotiation). However, the server treats this > EXACTLY as if the client had offered an empty RI extension, and > responds with its own RI extension (or if it doesn't implement the > full extension framework, just adds a known byte string to the end of > the ServerHello). In other words: > > > Client Server > ------------------------------------------------------ > ClientHello + TLS_RENEGO_PROTECTION_REQUEST -> > <- ServerHello + Empty RI > > > At this point, the client now knows that the server supports secure > renegotiation and can simply send RI in any renegotiation handshake > (and if the client doesn't implement the full extensions framework, it > could just add a known byte string to the end of the ClientHello, > without requiring full extension support). Note that this is > reminiscent of the SSLv2->SSLv3 transition where clients would > initially offer backward compatibility handshakes but once they knew > the server was SSLv3-capable would offer the new ClientHello. > > > What about 5246 and unsolicited extensions? > As far as I can tell, the major argument against using extensions > for S->C signalling is the 5246 prohibition against the server providing > unsolicited extensions. However, that was clearly intended to prevent > the server from sending extensions the client didn't expect and > that's not the case here. Moreover, we're updating 5246 so we can relax > the restriction for this extension (though I would think not in general). > > > What about not putting the verify data in the extension? > I think that issue is separable from the question of how we signal > support, so would like to deal with it separately. (It seems this > won't make any difference for the bigger questions like can deploying > the fix break things that currently work, or whether you can implement > the fix purely inside the TLS library) > > > What about SSLv3? > Obviously, the ClientHello is compatible with SSLv3. (and the magic > cipher suite can be offered even in SSLv2 backward compatible > hello---ugh!). Although SSLv3 does not have the TLS extension > framework, we could also specify that the server (once it sees the > magic cipher suite indicating the client supports this draft) just > appends the relevant fixed-length byte string to the end of the > ServerHello. > > > What do people think about this approach? > > -Ekr > > [*] I didn't invent this approach, I'm just reproposing it to try to focus > discussion. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ekr@networkresonance.com Wed Nov 25 14:53:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7EA23A67AA for ; Wed, 25 Nov 2009 14:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmH5X04D7yfj for ; Wed, 25 Nov 2009 14:53:38 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 079853A6B78 for ; Wed, 25 Nov 2009 14:53:38 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 42FB96C3288; Wed, 25 Nov 2009 14:54:08 -0800 (PST) Date: Wed, 25 Nov 2009 14:54:08 -0800 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B0D9B94.9080205@pobox.com> References: <4B0D9B94.9080205@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091125225408.42FB96C3288@kilo.networkresonance.com> Cc: TLS Working Group Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:53:38 -0000 At Wed, 25 Nov 2009 13:03:16 -0800, Michael D'Errico wrote: > > I think that it would be good to find a unified solution that > everybody is happy with, and believe that this may be it: This was actually suggested by Bodo Moeller last week. > 1) Client-to-Server signalling can be done in either of > two ways: > > A) an empty Secure_Renegotiation (SR) extension, or > B) a "magic" cipher suite > > 2) Server-to-Client signal is always an empty SR extension I just sent a message suggesting 1 and almost 2. > 3) Incorporate previous verify_data into Finished calc. I'm not happy with this, actually. This requires breaking the current clean definition of handshake hashes as the hash of all the handshake messages and simply adding some synthetic message in the middle. I don't think this is anywhere near as clean, as evidenced by the ongoing debate about whether to put it the synthetic data in the front, the back, incorporate it into the PRF, or chain the pre-existing handshake messages. [FWIW, I think I prefer the last of these implicit versions.] By contrast, RI allows that part of the system (which is well understood) to remain the same and in fact when RI is offered on the first handshake, there is no change to the TLS core at all. It's all just hashed into Finished as part of the ordinary TLS procedures, and everything is in fact compliant TLS, which I think is desirable. I appreciate that this is to some extent a matter of tradeoffs, but I don't find the arguments in favor of the implicit version very compelling when weighed against the above. -Ekr From lists@drh-consultancy.demon.co.uk Wed Nov 25 14:53:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB9A3A67AA for ; Wed, 25 Nov 2009 14:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 395mSVuzpCWA for ; Wed, 25 Nov 2009 14:53:58 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by core3.amsl.com (Postfix) with ESMTP id B68A13A6405 for ; Wed, 25 Nov 2009 14:53:58 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50441 helo=[192.168.7.8]) by relay01.mail.eu.clara.net (relay.clara.net [213.253.3.41]:10587) with esmtpa (authdaemon_plain:drh) id 1NDQkB-0003hE-5z (Exim 4.69) for tls@ietf.org (return-path ); Wed, 25 Nov 2009 22:53:52 +0000 Message-ID: <4B0DB583.5090404@drh-consultancy.demon.co.uk> Date: Wed, 25 Nov 2009 22:53:55 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <20091125223502.4265B6C3285@kilo.networkresonance.com> In-Reply-To: <20091125223502.4265B6C3285@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:53:59 -0000 Eric Rescorla wrote: > Folks, > > I wanted to try to resolve what I see as the major technical concern > people have about draft-ietf-tls-renegotiation-00, namely that the > client cannot offer secure renegotiation and be sure that it won't > cause a connection failure with a downrev (extension noncompliant) > server. > [details snipped] I like it! This addresses all my concerns. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From hovav@hovav.net Wed Nov 25 15:16:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A4C3A6B9C for ; Wed, 25 Nov 2009 15:16:46 -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 tKFzWpRYQ1Pj for ; Wed, 25 Nov 2009 15:16:46 -0800 (PST) Received: from iport-c1-out.ucsd.edu (iport-c1-out.ucsd.edu [132.239.0.176]) by core3.amsl.com (Postfix) with ESMTP id BA6AE3A68FA for ; Wed, 25 Nov 2009 15:16:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA1KDUuE7zNQ/2dsb2JhbADWC4QyBA X-IronPort-AV: E=Sophos;i="4.47,288,1257148800"; d="scan'208";a="135300281" Received: from csesmtp2.ucsd.edu (HELO cse-smtp.ucsd.edu) ([132.239.51.80]) by iport-c1-out.ucsd.edu with ESMTP/TLS/ADH-AES256-SHA; 25 Nov 2009 15:16:42 -0800 Received: from [192.168.1.113] (unknown [64.161.22.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cse-smtp.ucsd.edu (Postfix) with ESMTP id B969C5005C for ; Wed, 25 Nov 2009 15:16:41 -0800 (PST) Message-Id: <403BD255-2852-4524-90DF-BC32DB647FF2@hovav.net> From: Hovav Shacham To: TLS Working Group In-Reply-To: <20091125225408.42FB96C3288@kilo.networkresonance.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Nov 2009 15:16:12 -0800 References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> X-Mailer: Apple Mail (2.936) Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:16:47 -0000 On Nov 25, 2009, at 2:54 PM, Eric Rescorla wrote: > This requires breaking the current clean definition of handshake > hashes as the hash of all the handshake messages and simply adding > some synthetic message in the middle. > [...] > By contrast, RI allows that part of the system (which is well > understood) to remain the same and in fact when RI is offered on the > first handshake, there is no change to the TLS core at all. FWIW, I much prefer the RI approach. It leverages more of the preexisting TLS machinery, which makes is easier to reason about and more likely not to break things. Hovav. From mike-list@pobox.com Wed Nov 25 15:18:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E68A3A68FA for ; Wed, 25 Nov 2009 15:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 eWdQNrvzwxLj for ; Wed, 25 Nov 2009 15:18:39 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 1893C3A6873 for ; Wed, 25 Nov 2009 15:18:39 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C2E00A128E for ; Wed, 25 Nov 2009 18:18:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=5XTiD0Jj5NTK NDxA9izYn5Vasuc=; b=Dqpn2Ko8hG0SG4U1H99k7B6vBvPKVdjXama/lGYrZJC6 ntMcmP2P/6kR2Qrluj7qJDXOVniibZLR0DnRjFwFXl9U8YTVOM40GEMG8s1+7snV u7x3nKf9yHliZJqEPmMZG/Er1picBSABJudVTgpdHLD74YXEiTlldJrWk648B6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=CUMGaC ekLxNVKFQiQ1p0NYKKDom4Mx1KMUieCGobwxG2eugJ8cEmLV4qflqWCM0hlp3wpr BehgtRjjqTS8LUh6jzyc6nFyi77cFHPhib0sSO3SN6a6YAv1HWcQguA3fDrh1OQy ZotK29UREzsfQT8+Tsr98XnUEk4IriT76gX3Q= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id BF8C7A128D for ; Wed, 25 Nov 2009 18:18:33 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 35BD6A128C for ; Wed, 25 Nov 2009 18:18:32 -0500 (EST) Message-ID: <4B0DBB97.5050500@pobox.com> Date: Wed, 25 Nov 2009 15:19:51 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Working Group References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> In-Reply-To: <20091125225408.42FB96C3288@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D9E3D6E8-DA18-11DE-86CF-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:18:40 -0000 Eric Rescorla wrote: > Michael D'Errico wrote: >> I think that it would be good to find a unified solution that >> everybody is happy with, and believe that this may be it: > > This was actually suggested by Bodo Moeller last week. Yes, I just reread his message of Nov. 15 which states: One way to avoid most of the overhead from the current ID would be to keep the extension *always* empty. If the client and server both send it during any given handshake, then the Finished messages concluding that handshake will be computed mostly in the standard way, but if it's a renegotiation handshake, including the previous handshake's Finished messages in the handshake_ messages that will be hashed. [Open question: Where should they go? Maybe the easiest is to always hash them at the end; client first, server second.] >> 1) Client-to-Server signalling can be done in either of >> two ways: >> >> A) an empty Secure_Renegotiation (SR) extension, or >> B) a "magic" cipher suite >> >> 2) Server-to-Client signal is always an empty SR extension > > I just sent a message suggesting 1 and almost 2. Great, we are getting closer. >> 3) Incorporate previous verify_data into Finished calc. > > I'm not happy with this, actually. > > This requires breaking the current clean definition of handshake > hashes as the hash of all the handshake messages and simply adding > some synthetic message in the middle. I don't think this is anywhere > near as clean, as evidenced by the ongoing debate about whether to put > it the synthetic data in the front, the back, incorporate it into the > PRF, or chain the pre-existing handshake messages. [FWIW, I think I > prefer the last of these implicit versions.] > > By contrast, RI allows that part of the system (which is well > understood) to remain the same and in fact when RI is offered on the > first handshake, there is no change to the TLS core at all. It's all > just hashed into Finished as part of the ordinary TLS procedures, > and everything is in fact compliant TLS, which I think is desirable. > > I appreciate that this is to some extent a matter of tradeoffs, > but I don't find the arguments in favor of the implicit version > very compelling when weighed against the above. I think that moving forward to TLS 1.3 and beyond, we really want the old verify_data incorporated directly into Finished, don't we? Using an extension for this only makes sense because we need to patch old versions. The complaint I have about sending the verify_data over the wire is that that alone does not plug the hole. You need to take the extra step to check that it's correct, and a maintenance programmer not intimately familiar with TLS might miss this fact. Changing Finished to the way we would like it in TLS 1.3 and beyond seems like a better way to proceed. Chaining the previous handshake messages with the renegotiation does seem like a cleaner approach than inserting the old verify_data into the handshake stream, so I'd support that if that's the consensus. Mike From ekr@networkresonance.com Wed Nov 25 15:24:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D7E3A6B74 for ; Wed, 25 Nov 2009 15:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.173 X-Spam-Level: X-Spam-Status: No, score=0.173 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP3cH+nLcES3 for ; Wed, 25 Nov 2009 15:24:16 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id E57263A69C7 for ; Wed, 25 Nov 2009 15:24:15 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 24F2A6C32B0; Wed, 25 Nov 2009 15:24:45 -0800 (PST) Date: Wed, 25 Nov 2009 15:24:45 -0800 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B0DBB97.5050500@pobox.com> References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <4B0DBB97.5050500@pobox.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091125232446.24F2A6C32B0@kilo.networkresonance.com> Cc: TLS Working Group Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:24:16 -0000 At Wed, 25 Nov 2009 15:19:51 -0800, Michael D'Errico wrote: > The complaint I have about sending the verify_data over the wire is > that that alone does not plug the hole. You need to take the extra > step to check that it's correct, and a maintenance programmer not > intimately familiar with TLS might miss this fact. I don't find this argument very compelling. There are all sorts of ways to screw up your TLS implementation that are worse than this and are difficult/impossible to detect from the other side. E.g., - Weak randomness - Failure to check buffers leading to buffer overflows - Failure to check certs TLS relies throughout on the assumption that the other side is implemented more or less correctly. If we can't count on that, we have bigger problems than this issue. -Ekr From rrelyea@redhat.com Wed Nov 25 15:28:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9073A6974 for ; Wed, 25 Nov 2009 15:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 WAN-ElliTx9w for ; Wed, 25 Nov 2009 15:28:34 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id D048F3A69C4 for ; Wed, 25 Nov 2009 15:28:34 -0800 (PST) Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAPNSTui007960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Nov 2009 18:28:29 -0500 Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAPNSSFu009089 for ; Wed, 25 Nov 2009 18:28:28 -0500 Message-ID: <4B0DBD9C.1090703@REDHAT.COM> Date: Wed, 25 Nov 2009 15:28:28 -0800 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: tls@ietf.org References: <20091125223502.4265B6C3285@kilo.networkresonance.com> In-Reply-To: <20091125223502.4265B6C3285@kilo.networkresonance.com> X-Enigmail-Version: 0.97a Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080701010805090403090009" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.17 Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:28:35 -0000 This is a cryptographically signed message in MIME format. --------------ms080701010805090403090009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/25/2009 02:35 PM, Eric Rescorla wrote: > Folks, > > I wanted to try to resolve what I see as the major technical concern > people have about draft-ietf-tls-renegotiation-00, namely that the > client cannot offer secure renegotiation and be sure that it won't > cause a connection failure with a downrev (extension noncompliant) > server. > > There's been a lot of discussion of whether this is a serious problem, > but it's clear that minimal risk of breaking things that currently > work (which some folks think requires not using extensions in the > initial ClientHello) is important for the timely deployment of the > fix, and with the current draft, that may require fall-back to > extension-less handshake. > =20 This is not an RI specific issue. TLS already defines a number of extensions. This fallback policy was implemented not because extension noncompliant servers were particularly important, but because implementations needed to have minimal objections for moving forward and actually using extensions. Today TLS clients regularly use extensions, so adding one more to allow renegotiation should not be an issue. > =20 > It's unclear how often such fall-back logic would actually be needed, > and I do find Nelson's "tough love" approach here sort of appealing, > but it does seem to be a problem that you don't necessarily know for su= re=20 > whether you need it or not until you've actually shipped the product=20 > with extensions, and possibly broken applications that currently work. = > It's especially concerning that fall-back can't be implemented reliably= > inside the TLS library, e.g., if you just get a filehandle, so changes > to the app logic are required. > =20 I think we already have a handle on this. Most modern browsers already send extensions in their initial handshakes. This change has been responsible for the final demise of SSLv2. The whole idea that extensions are rare just doesn't match with today's reality. Yes, there are some implementations that can't handle them. That is a very small percentage compared to the number of implementations that can't safely renegotiate (e.i. 100% of them). Those implementations already have to deal with a world in which extensions are real and common. They also have to deal with a world in which their code will need to be patched in order to be safe anyway. > The rest of this message describes a simple modification [*] to > draft-ietf-tls-negotiation which I think addresses this compatibility > issue without requiring fall-back. > > The idea is to use a magic cipher suite to signal that the client can > securely renegotiate (as described in > draft-mrex-tls-secure-renegotiation).=20 I'm not excited about the magic cipher suite hack for SSLv3, but I can live with it if I have to. I am strongly opposed to extending it to TLS. In the TLS world extensions are expected, normal, and now common. There is no reason to overload a field created specifically to determine a compatible cipher suite with something that extensions are designed to do= =2E bob --------------ms080701010805090403090009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV7DCC Bv8wggXnoAMCAQICAwCrKTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MTAxNDAwMDAwMVoXDTEwMTAxNDIwNTQyMVowbjEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9dBmw8V94Rx84iwE5RpiO+uHKS5e91CHnKf JsbEOzPxS7Hgizt78ratBbhkudQ7bJIH1o9nh0Q5c/LdOlWUF1Jn+3+JNGvs6h/vlmfCYGPK TZpUbwPm8Rmik+bDNlAOUkDieZHfUg8HOdGrqvp1prqqwLMzgovi5YiETf28SO9kxNqjkbBL VxsBlHrnjG1dmn8jAYZ1XPctXMEsHV+2EISDOPYWl/CE2jt7km6Hkxq7D6p/z8Ef9Zn/uZ1z onthvoDp+BJOIIa6s68r9rLGNtAQ5/OtxXKpk6Cz5SAUgZIo0p2tNyQ2hFy8ojUZm2hNKVfu 6lN9DcSU0sri8I0S1QIDAQABo4IDhTCCA4EwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6fisKv/TEZ8c96u/L+x4d RtrwdjCBqAYDVR0jBIGgMIGdgBRTcu2SnODaywFcfH6WNU7y1LhRgqGBgaR/MH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eYIBDTAdBgNVHREEFjAUgRJycmVseWVhQHJlZGhhdC5jb20wggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNz bC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRk LjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8E XDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAOBrTD2DJvI0rP6phlUjV0JU6owP2XLQ2fZZ42J LHqfJ+yJWqpprzbHK7c7oJjy/TlNUQzFQZvtQM0WAcopsOzvqeXyB9lt6Zqq1ULMG9s5yMM0 rq/dpYFE2ju9WY8+7962iSkqGmMwrq9ZwO8J37zmMDS3ifw3/n3/Ns1t7MK6tanzkugScuW9 TQr/zQNNanLQmeuvU6Fbru6UFZI6c1qW0G4B1ptfTEQiAQ+E7PdIdjI9SYd24uU6/OdPlGrV tgl0UUnwLuCwA+D84xtc4+TjkLFxuqKCTi0NDONzosPzrNGJ7Kcau5bqV5AUxVz6bUifqQ3a X7xgD7Vq0EGCCK4wggb/MIIF56ADAgECAgMAqykwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0wOTEwMTQwMDAwMDFaFw0xMDEwMTQyMDU0 MjFaMG4xHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVk aGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfXQZsPFfeEcfOIsBOU aYjvrhykuXvdQh5ynybGxDsz8Uux4Is7e/K2rQW4ZLnUO2ySB9aPZ4dEOXPy3TpVlBdSZ/t/ iTRr7Oof75ZnwmBjyk2aVG8D5vEZopPmwzZQDlJA4nmR31IPBznRq6r6daa6qsCzM4KL4uWI hE39vEjvZMTao5GwS1cbAZR654xtXZp/IwGGdVz3LVzBLB1fthCEgzj2FpfwhNo7e5Juh5Ma uw+qf8/BH/WZ/7mdc6J7Yb6A6fgSTiCGurOvK/ayxjbQEOfzrcVyqZOgs+UgFIGSKNKdrTck NoRcvKI1GZtoTSlX7upTfQ3ElNLK4vCNEtUCAwEAAaOCA4UwggOBMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+n4r Cr/0xGfHPervy/seHUba8HYwgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKh gYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQu Y29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQW DVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEt Y3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADga0w9gybyNKz+qYZVI1d CVOqMD9ly0Nn2WeNiSx6nyfsiVqqaa82xyu3O6CY8v05TVEMxUGb7UDNFgHKKbDs76nl8gfZ bemaqtVCzBvbOcjDNK6v3aWBRNo7vVmPPu/etokpKhpjMK6vWcDvCd+85jA0t4n8N/59/zbN bezCurWp85LoEnLlvU0K/80DTWpy0Jnrr1OhW67ulBWSOnNaltBuAdabX0xEIgEPhOz3SHYy PUmHduLlOvznT5Rq1bYJdFFJ8C7gsAPg/OMbXOPk45Cxcbqigk4tDQzjc6LD86zRieynGruW 6leQFMVc+m1In6kN2l+8YA+1atBBggiuMIIH4jCCBcqgAwIBAgIBDTANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGB pH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkw VzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w b2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0 ZXMwDQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP /4H/Bc8FFDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhp cqMr3OyzK3aYGJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyR WTTX6mWSv+TraOwuj3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNh HeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG8 59MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6Gu UcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf 6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIO uAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdC taW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/TyxV/stlehMYID0DCC A8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMAkGBSsO AwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5 MTEyNTIzMjgyOFowIwYJKoZIhvcNAQkEMRYEFFClGq3HcYYm1imtOkU5GNxmQNPzMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBAIJUjmUjkUIkWWA2lB1EE+9RjZ9Vspd9DQp5HPxOLOih/MqV5/LW mEfNccfP3h2sCSjJqregBfzMWchcrcu95iqYvErIuYmxmWFH5qXe8b8Lak9u+BMRBLNp/jNL 5n9NEe8eDyDeosanB1ru3KxklfurGQfUwmjp530TKKUfD5DacibmlN5s4HIIMQvzngVi0rgS otChYjV9en3r+kz/eJMKMenuUEXtBIJnBlL9D1MDR/+jrMzi4lyYWMLxCR85RBw7VS/SdzTn X22/9tvXWnlPv55BTnhFEu/O+Qrs5AnetsSnDZkNAXgKRNBffW9T0eX9fGb9Z5ew0Eu0CGaH 1QAAAAAAAAA= --------------ms080701010805090403090009-- From mrex@sap.com Wed Nov 25 15:32:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C1F3A6878 for ; Wed, 25 Nov 2009 15:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 3oy-MxJ8bIca for ; Wed, 25 Nov 2009 15:32:52 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DE9B03A6405 for ; Wed, 25 Nov 2009 15:32:51 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAPNWjWC025037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 00:32:45 +0100 (MET) From: Martin Rex Message-Id: <200911252332.nAPNWi0m003638@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Thu, 26 Nov 2009 00:32:43 +0100 (MET) In-Reply-To: <20091125225408.42FB96C3288@kilo.networkresonance.com> from "Eric Rescorla" at Nov 25, 9 02:54:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:32:53 -0000 Eric Rescorla wrote: > > At Wed, 25 Nov 2009 13:03:16 -0800, > Michael D'Errico wrote: > > > > I think that it would be good to find a unified solution that > > everybody is happy with, and believe that this may be it: > > This was actually suggested by Bodo Moeller last week. It's one of the options I summarized two weeks ago: http://www.ietf.org/mail-archive/web/tls/current/msg04115.html > > > 3) Incorporate previous verify_data into Finished calc. > > I'm not happy with this, actually. > > This requires breaking the current clean definition of handshake > hashes as the hash of all the handshake messages and simply adding > some synthetic message in the middle. I don't think this is anywhere > near as clean, as evidenced by the ongoing debate about whether to put > it the synthetic data in the front, the back, incorporate it into the > PRF, or chain the pre-existing handshake messages. [FWIW, I think I > prefer the last of these implicit versions.] I *really* prefer this. It's perfectly clean, and when doing it right after ServerHello, it ends up at the same position as if it was sent by the server in ServerHello. > > By contrast, RI allows that part of the system (which is well > understood) That change is certainly _not_ going to break anything and well within the "well understood" domain. I explained it here: http://www.ietf.org/mail-archive/web/tls/current/msg04194.html -Martin From rrelyea@redhat.com Wed Nov 25 15:33:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31D23A6B78 for ; Wed, 25 Nov 2009 15:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 SrpvW6QXRAyw for ; Wed, 25 Nov 2009 15:33:51 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id CF6E03A697C for ; Wed, 25 Nov 2009 15:33:50 -0800 (PST) Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAPNXjaK011874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Nov 2009 18:33:46 -0500 Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAPNXjuh022949 for ; Wed, 25 Nov 2009 18:33:45 -0500 Message-ID: <4B0DBED9.9010001@REDHAT.COM> Date: Wed, 25 Nov 2009 15:33:45 -0800 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: tls@ietf.org References: <200911252234.nAPMYZAx029809@fs4113.wdf.sap.corp> In-Reply-To: <200911252234.nAPMYZAx029809@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.97a Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020603020604060809020108" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.18 Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:33:51 -0000 This is a cryptographically signed message in MIME format. --------------ms020603020604060809020108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/25/2009 02:34 PM, Martin Rex wrote: > Nelson B Bolyard wrote: > =20 >> On 2009-11-25 01:39 PST, Yoav Nir wrote: >> =20 >>> On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote: >>> >>> =20 >>>> So how would this work as a middle way between the proposals: >>>> >>>> C->S Signaling: >>>> 1) Client MUST include either the magic CipherSuite or RI extension = or both >>>> 2a) TLS compatible server MUST support magic CipherSuite and RI. >>>> 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI >>>> =20 >>> How about: >>> 2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI >>> 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY = support RI >>> =20 >> Why would you separate TLS 1.0 servers from TLS 1.1+ ? >> =20 > Maybe because a large number of TLS 1.0 servers do not support TLS exte= nsions > (rightly so), they're just extensions-tolerant. > =20 er, a small number of incorrectly coded TLS 1.0 servers do not support TLS extensions. A large number of TLS 1.0 servers do, and have done so for a long time. A *large* number of TLS 1.0 clients already send extensions today. If your TLS 1.0 code does not handle extensions, please fix it. thanks, bob --------------ms020603020604060809020108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV7DCC Bv8wggXnoAMCAQICAwCrKTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MTAxNDAwMDAwMVoXDTEwMTAxNDIwNTQyMVowbjEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9dBmw8V94Rx84iwE5RpiO+uHKS5e91CHnKf JsbEOzPxS7Hgizt78ratBbhkudQ7bJIH1o9nh0Q5c/LdOlWUF1Jn+3+JNGvs6h/vlmfCYGPK TZpUbwPm8Rmik+bDNlAOUkDieZHfUg8HOdGrqvp1prqqwLMzgovi5YiETf28SO9kxNqjkbBL VxsBlHrnjG1dmn8jAYZ1XPctXMEsHV+2EISDOPYWl/CE2jt7km6Hkxq7D6p/z8Ef9Zn/uZ1z onthvoDp+BJOIIa6s68r9rLGNtAQ5/OtxXKpk6Cz5SAUgZIo0p2tNyQ2hFy8ojUZm2hNKVfu 6lN9DcSU0sri8I0S1QIDAQABo4IDhTCCA4EwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6fisKv/TEZ8c96u/L+x4d RtrwdjCBqAYDVR0jBIGgMIGdgBRTcu2SnODaywFcfH6WNU7y1LhRgqGBgaR/MH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eYIBDTAdBgNVHREEFjAUgRJycmVseWVhQHJlZGhhdC5jb20wggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNz bC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRk LjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8E XDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAOBrTD2DJvI0rP6phlUjV0JU6owP2XLQ2fZZ42J LHqfJ+yJWqpprzbHK7c7oJjy/TlNUQzFQZvtQM0WAcopsOzvqeXyB9lt6Zqq1ULMG9s5yMM0 rq/dpYFE2ju9WY8+7962iSkqGmMwrq9ZwO8J37zmMDS3ifw3/n3/Ns1t7MK6tanzkugScuW9 TQr/zQNNanLQmeuvU6Fbru6UFZI6c1qW0G4B1ptfTEQiAQ+E7PdIdjI9SYd24uU6/OdPlGrV tgl0UUnwLuCwA+D84xtc4+TjkLFxuqKCTi0NDONzosPzrNGJ7Kcau5bqV5AUxVz6bUifqQ3a X7xgD7Vq0EGCCK4wggb/MIIF56ADAgECAgMAqykwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0wOTEwMTQwMDAwMDFaFw0xMDEwMTQyMDU0 MjFaMG4xHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVk aGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfXQZsPFfeEcfOIsBOU aYjvrhykuXvdQh5ynybGxDsz8Uux4Is7e/K2rQW4ZLnUO2ySB9aPZ4dEOXPy3TpVlBdSZ/t/ iTRr7Oof75ZnwmBjyk2aVG8D5vEZopPmwzZQDlJA4nmR31IPBznRq6r6daa6qsCzM4KL4uWI hE39vEjvZMTao5GwS1cbAZR654xtXZp/IwGGdVz3LVzBLB1fthCEgzj2FpfwhNo7e5Juh5Ma uw+qf8/BH/WZ/7mdc6J7Yb6A6fgSTiCGurOvK/ayxjbQEOfzrcVyqZOgs+UgFIGSKNKdrTck NoRcvKI1GZtoTSlX7upTfQ3ElNLK4vCNEtUCAwEAAaOCA4UwggOBMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+n4r Cr/0xGfHPervy/seHUba8HYwgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKh gYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQu Y29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQW DVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEt Y3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADga0w9gybyNKz+qYZVI1d CVOqMD9ly0Nn2WeNiSx6nyfsiVqqaa82xyu3O6CY8v05TVEMxUGb7UDNFgHKKbDs76nl8gfZ bemaqtVCzBvbOcjDNK6v3aWBRNo7vVmPPu/etokpKhpjMK6vWcDvCd+85jA0t4n8N/59/zbN bezCurWp85LoEnLlvU0K/80DTWpy0Jnrr1OhW67ulBWSOnNaltBuAdabX0xEIgEPhOz3SHYy PUmHduLlOvznT5Rq1bYJdFFJ8C7gsAPg/OMbXOPk45Cxcbqigk4tDQzjc6LD86zRieynGruW 6leQFMVc+m1In6kN2l+8YA+1atBBggiuMIIH4jCCBcqgAwIBAgIBDTANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGB pH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkw VzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w b2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0 ZXMwDQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP /4H/Bc8FFDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhp cqMr3OyzK3aYGJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyR WTTX6mWSv+TraOwuj3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNh HeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG8 59MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6Gu UcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf 6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIO uAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdC taW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/TyxV/stlehMYID0DCC A8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMAkGBSsO AwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5 MTEyNTIzMzM0NVowIwYJKoZIhvcNAQkEMRYEFKU6qM2WwkaW72Jalfc/fQ/xxRByMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBAFTLcYfIpwpLjRAs0TvIOofpwkdS4UfDbn/jACVNObXmEkbg0aMF w7RHwxeOWz+hBslduHtt2iWEy40nGFKSaTieMarAzirJxuYIr+f0vP/eyKm+DADzRljxnTkc 4TgOBqJMloQU2V+o32ae/+J33TLCs5msiEgbFKgIIxicqqwmn7mwxHE5fU9v7VDZduE88l3T qpHv8wAs7S8mR+j64UIn9KtUnRBKHPh1UPQpuEmOcQUIhxIN6Dfq8B1Sih8yvP3tgGWKVD+W h1POFQkK2YMZe0WqLvfrxxekccEh2pkMweZ2zr8xqRiJp9eeHJYrSLAhjMH2shnbwyBckhJz CrsAAAAAAAA= --------------ms020603020604060809020108-- From mrex@sap.com Wed Nov 25 15:49:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0444D3A6997 for ; Wed, 25 Nov 2009 15:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 1w3lyeERsnvs for ; Wed, 25 Nov 2009 15:49:04 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 0EF5A3A697C for ; Wed, 25 Nov 2009 15:49:03 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAPNmvGB007259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 00:48:57 +0100 (MET) From: Martin Rex Message-Id: <200911252348.nAPNmu8C004590@fs4113.wdf.sap.corp> To: rrelyea@redhat.com (Robert Relyea) Date: Thu, 26 Nov 2009 00:48:56 +0100 (MET) In-Reply-To: <4B0DBED9.9010001@REDHAT.COM> from "Robert Relyea" at Nov 25, 9 03:33:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:49:05 -0000 Robert Relyea wrote: > > > >> Why would you separate TLS 1.0 servers from TLS 1.1+ ? > >> > > Maybe because a large number of TLS 1.0 servers do not support TLS extensions > > (rightly so), they're just extensions-tolerant. > > > er, a small number of incorrectly coded TLS 1.0 servers do not support > TLS extensions. > A large number of TLS 1.0 servers do, and have done so for a long time. > A *large* number of TLS 1.0 clients already send extensions today. > > If your TLS 1.0 code does not handle extensions, please fix it. Your statement is at least ambiguous. TLSv1.0 (rfc-2246) and TLSv1.1 (rfc-4346) both do clearly *NOT* support TLS extensions, they're both _only_ extensions-tolerant. TLSv1.2 is the first protocol version of TLS that supports TLS extensions in the base spec. -Martin From ekr@networkresonance.com Wed Nov 25 16:05:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4CEA3A6819 for ; Wed, 25 Nov 2009 16:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRDmxphIdY1H for ; Wed, 25 Nov 2009 16:05:23 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id D2C863A6835 for ; Wed, 25 Nov 2009 16:05:23 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 46FD16C32C9; Wed, 25 Nov 2009 16:05:53 -0800 (PST) Date: Wed, 25 Nov 2009 16:05:53 -0800 From: Eric Rescorla To: Robert Relyea In-Reply-To: <4B0DBD9C.1090703@REDHAT.COM> References: <20091125223502.4265B6C3285@kilo.networkresonance.com> <4B0DBD9C.1090703@REDHAT.COM> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091126000553.46FD16C32C9@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:05:24 -0000 At Wed, 25 Nov 2009 15:28:28 -0800, Robert Relyea wrote: > > It's unclear how often such fall-back logic would actually be needed, > > and I do find Nelson's "tough love" approach here sort of appealing, > > but it does seem to be a problem that you don't necessarily know for sure > > whether you need it or not until you've actually shipped the product > > with extensions, and possibly broken applications that currently work. > > It's especially concerning that fall-back can't be implemented reliably > > inside the TLS library, e.g., if you just get a filehandle, so changes > > to the app logic are required. > > > I think we already have a handle on this. Most modern browsers already > send extensions in their initial handshakes. This change has been > responsible for the final demise of SSLv2. > > The whole idea that extensions are rare just doesn't match with today's > reality. Yes, there are some implementations that can't handle them. > That is a very small percentage compared to the number of > implementations that can't safely renegotiate (e.i. 100% of them). Those > implementations already have to deal with a world in which extensions > are real and common. They also have to deal with a world in which their > code will need to be patched in order to be safe anyway. > > > The rest of this message describes a simple modification [*] to > > draft-ietf-tls-negotiation which I think addresses this compatibility > > issue without requiring fall-back. > > > > The idea is to use a magic cipher suite to signal that the client can > > securely renegotiate (as described in > > draft-mrex-tls-secure-renegotiation). > I'm not excited about the magic cipher suite hack for SSLv3, but I can > live with it if I have to. I am strongly opposed to extending it to TLS. > In the TLS world extensions are expected, normal, and now common. There > is no reason to overload a field created specifically to determine a > compatible cipher suite with something that extensions are designed to do. I'd be very interested in seeing data on what fraction of existing servers can't handle extensions. Is there any chance that you have measurements? Thanks, -Ekr From marsh@extendedsubset.com Wed Nov 25 16:07:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B1D3A6819 for ; Wed, 25 Nov 2009 16:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 6i1vr5oGn-DP for ; Wed, 25 Nov 2009 16:07:51 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 6AC403A67E3 for ; Wed, 25 Nov 2009 16:07:51 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDRti-000J3m-5J; Thu, 26 Nov 2009 00:07:46 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0A09B603A; Thu, 26 Nov 2009 00:07:45 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Y5Vql5Vzisxtoqojn8xbEmv8Cou0o4Vw= Message-ID: <4B0DC6CE.3040603@extendedsubset.com> Date: Wed, 25 Nov 2009 18:07:42 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Relyea References: <200911252234.nAPMYZAx029809@fs4113.wdf.sap.corp> <4B0DBED9.9010001@REDHAT.COM> In-Reply-To: <4B0DBED9.9010001@REDHAT.COM> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:07:52 -0000 Robert Relyea wrote: > > If your TLS 1.0 code does not handle extensions, please fix it. Easy enough. But what if it's not your code? Pretend you're an IT admin who just rolled out the patch to every PC in the company last night, and today the groundskeeper opens a support ticket because he can't access the management interface to the automated lawn sprinkler system. You say "please fix it". "What, the sprinklers?" he says. "They're working fine. It's just since you rebooted the PC last night the winder just gets stuck there waitin' on the sprinkler login page." You say "please fix it". "I thought that was your job. Besides, I got a truckload of mulch and and a work crew to spread it coming in 30 minutes. If I don't change the timing on them sprinklers they're going to cut on right when they get working. You'll have a dozen muddy landscapers on your hands though, and they ain't got no sense of humor. I'll just tell em you're gonna fix it." You say "please fix it". "All right, all right. I'll try calling the sprinkler company. Won't do any good though, they got rid of all the people who knew what they were doing so we stopped paying maintenance on that thing at the beginning of the year. They won't talk to us since. Planning to replace it in the fall, ya see." Stay tuned next week for the hilarious conclusion of "Muddy MIS Mixup". - Marsh From nelson@bolyard.me Wed Nov 25 16:16:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48B23A6891 for ; Wed, 25 Nov 2009 16:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 gC+SHv0pgZl9 for ; Wed, 25 Nov 2009 16:16:15 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 1B0EC3A6843 for ; Wed, 25 Nov 2009 16:16:15 -0800 (PST) Received: (qmail 30916 invoked from network); 26 Nov 2009 00:16:08 -0000 Received: from unknown (24.5.142.42) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 26 Nov 2009 00:16:08 -0000 Message-ID: <4B0DC942.7060900@bolyard.me> Date: Wed, 25 Nov 2009 16:18:10 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Robert Relyea References: <200911252234.nAPMYZAx029809@fs4113.wdf.sap.corp> <4B0DBED9.9010001@REDHAT.COM> In-Reply-To: <4B0DBED9.9010001@REDHAT.COM> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:16:16 -0000 On 2009-11-25 15:33 PST, Robert Relyea wrote: > er, a small number of incorrectly coded TLS 1.0 servers do not support > TLS extensions. > A large number of TLS 1.0 servers do, and have done so for a long time. > A *large* number of TLS 1.0 clients already send extensions today. > > If your TLS 1.0 code does not handle extensions, please fix it. Bob, when you wrote "support", I suspect you meant "tolerate". Right? From mike-list@pobox.com Wed Nov 25 16:23:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0FD3A67AF for ; Wed, 25 Nov 2009 16:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 PIv3c-4BJbdd for ; Wed, 25 Nov 2009 16:23:53 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id B8CCF3A67AB for ; Wed, 25 Nov 2009 16:23:53 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B91FF826B5 for ; Wed, 25 Nov 2009 19:23:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=6bwM2zXZe2TG LwyEva9n5auKstA=; b=l4MTv3oLo/rBO5L154QCRYQ8rZGd3m7VMKlbUeK8Npwr mwL0eN/RL6f9s8ChsGsrAOg1vr9ymdShctCKlhT/Ba+oBK6KLrqWmAdLR5UNPmjm N3BQ48ecRjSl4YdqR4hNLxctV6P/RxbSGwvQrgiJr0Ju9TmN/8m+67QOEJFK5LA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=BI5HmT 5Y7SHsYsBk4RmWvz3A/ypnrFNdNyg88zobjzoEU8CHz0t06dZ9yPBFnUMA22gx78 F1Eh+8Qx0ZPu5sa0hpZvkqCQNxllL07VPmCiAnkmkstriSTTcGOWlWLSprxsCE3m pn6f/Wr6uYXvT1/jLRjobsijognPHr0vHf3RM= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id AD987826B3 for ; Wed, 25 Nov 2009 19:23:46 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 1A5A4826B2 for ; Wed, 25 Nov 2009 19:23:45 -0500 (EST) Message-ID: <4B0DCAE0.80907@pobox.com> Date: Wed, 25 Nov 2009 16:25:04 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Working Group References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <4B0DBB97.5050500@pobox.com> <20091125232446.24F2A6C32B0@kilo.networkresonance.com> In-Reply-To: <20091125232446.24F2A6C32B0@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: F62E9A96-DA21-11DE-9465-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:23:54 -0000 Eric Rescorla wrote: > Michael D'Errico wrote: >> The complaint I have about sending the verify_data over the wire is >> that that alone does not plug the hole. You need to take the extra >> step to check that it's correct, and a maintenance programmer not >> intimately familiar with TLS might miss this fact. > > I don't find this argument very compelling. There are all sorts of > ways to screw up your TLS implementation that are worse than this > and are difficult/impossible to detect from the other side. E.g., > > - Weak randomness > - Failure to check buffers leading to buffer overflows > - Failure to check certs My position is: if we can avoid adding another one to this list, then we should. Mike > TLS relies throughout on the assumption that the other side is > implemented more or less correctly. If we can't count on that, > we have bigger problems than this issue. > > -Ekr From rrelyea@redhat.com Wed Nov 25 16:34:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93133A67DB for ; Wed, 25 Nov 2009 16:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 i3x-R6oXKSsX for ; Wed, 25 Nov 2009 16:34:22 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 1F9693A67AF for ; Wed, 25 Nov 2009 16:34:22 -0800 (PST) Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAQ0YFsS006498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2009 19:34:16 -0500 Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAQ0YDpI004743; Wed, 25 Nov 2009 19:34:15 -0500 Message-ID: <4B0DCD05.3080103@REDHAT.COM> Date: Wed, 25 Nov 2009 16:34:13 -0800 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Marsh Ray References: <200911252234.nAPMYZAx029809@fs4113.wdf.sap.corp> <4B0DBED9.9010001@REDHAT.COM> <4B0DC6CE.3040603@extendedsubset.com> In-Reply-To: <4B0DC6CE.3040603@extendedsubset.com> X-Enigmail-Version: 0.97a Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090504020303050901070602" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21 Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:34:22 -0000 This is a cryptographically signed message in MIME format. --------------ms090504020303050901070602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/25/2009 04:07 PM, Marsh Ray wrote: > Robert Relyea wrote: > =20 >> If your TLS 1.0 code does not handle extensions, please fix it. >> =20 > Easy enough. But what if it's not your code? > =20 My statement was to the TLS 1.0 coder, not to the IT administrator. It was on behalf of that IT administrator that I make the statement. It was the IT administrator that we had in mind when we implemented fallback solutions for extension intolerant servers. In this case, the IT administrator needs to eventually get a patch for *all* of his servers and clients. Designing systems assuming that the new clients will not send TLS extensions --- event TLS 1.0 clients is already ignoring the real world. Client send extensions. They will continue to do so. TLS 1.0 servers already parse these extensions. RI is just one more on the list. Clients already tiptoe around the broken implementations. This is not new. RI does not cause it, it is already happening. These implementations will have to be patched at some point anyway, they may as well be patched to at least be tolerant of extensions. bob --------------ms090504020303050901070602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV7DCC Bv8wggXnoAMCAQICAwCrKTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MTAxNDAwMDAwMVoXDTEwMTAxNDIwNTQyMVowbjEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9dBmw8V94Rx84iwE5RpiO+uHKS5e91CHnKf JsbEOzPxS7Hgizt78ratBbhkudQ7bJIH1o9nh0Q5c/LdOlWUF1Jn+3+JNGvs6h/vlmfCYGPK TZpUbwPm8Rmik+bDNlAOUkDieZHfUg8HOdGrqvp1prqqwLMzgovi5YiETf28SO9kxNqjkbBL VxsBlHrnjG1dmn8jAYZ1XPctXMEsHV+2EISDOPYWl/CE2jt7km6Hkxq7D6p/z8Ef9Zn/uZ1z onthvoDp+BJOIIa6s68r9rLGNtAQ5/OtxXKpk6Cz5SAUgZIo0p2tNyQ2hFy8ojUZm2hNKVfu 6lN9DcSU0sri8I0S1QIDAQABo4IDhTCCA4EwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6fisKv/TEZ8c96u/L+x4d RtrwdjCBqAYDVR0jBIGgMIGdgBRTcu2SnODaywFcfH6WNU7y1LhRgqGBgaR/MH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eYIBDTAdBgNVHREEFjAUgRJycmVseWVhQHJlZGhhdC5jb20wggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNz bC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRk LjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8E XDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAOBrTD2DJvI0rP6phlUjV0JU6owP2XLQ2fZZ42J LHqfJ+yJWqpprzbHK7c7oJjy/TlNUQzFQZvtQM0WAcopsOzvqeXyB9lt6Zqq1ULMG9s5yMM0 rq/dpYFE2ju9WY8+7962iSkqGmMwrq9ZwO8J37zmMDS3ifw3/n3/Ns1t7MK6tanzkugScuW9 TQr/zQNNanLQmeuvU6Fbru6UFZI6c1qW0G4B1ptfTEQiAQ+E7PdIdjI9SYd24uU6/OdPlGrV tgl0UUnwLuCwA+D84xtc4+TjkLFxuqKCTi0NDONzosPzrNGJ7Kcau5bqV5AUxVz6bUifqQ3a X7xgD7Vq0EGCCK4wggb/MIIF56ADAgECAgMAqykwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0wOTEwMTQwMDAwMDFaFw0xMDEwMTQyMDU0 MjFaMG4xHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVk aGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfXQZsPFfeEcfOIsBOU aYjvrhykuXvdQh5ynybGxDsz8Uux4Is7e/K2rQW4ZLnUO2ySB9aPZ4dEOXPy3TpVlBdSZ/t/ iTRr7Oof75ZnwmBjyk2aVG8D5vEZopPmwzZQDlJA4nmR31IPBznRq6r6daa6qsCzM4KL4uWI hE39vEjvZMTao5GwS1cbAZR654xtXZp/IwGGdVz3LVzBLB1fthCEgzj2FpfwhNo7e5Juh5Ma uw+qf8/BH/WZ/7mdc6J7Yb6A6fgSTiCGurOvK/ayxjbQEOfzrcVyqZOgs+UgFIGSKNKdrTck NoRcvKI1GZtoTSlX7upTfQ3ElNLK4vCNEtUCAwEAAaOCA4UwggOBMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+n4r Cr/0xGfHPervy/seHUba8HYwgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKh gYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQu Y29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQW DVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEt Y3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADga0w9gybyNKz+qYZVI1d CVOqMD9ly0Nn2WeNiSx6nyfsiVqqaa82xyu3O6CY8v05TVEMxUGb7UDNFgHKKbDs76nl8gfZ bemaqtVCzBvbOcjDNK6v3aWBRNo7vVmPPu/etokpKhpjMK6vWcDvCd+85jA0t4n8N/59/zbN bezCurWp85LoEnLlvU0K/80DTWpy0Jnrr1OhW67ulBWSOnNaltBuAdabX0xEIgEPhOz3SHYy PUmHduLlOvznT5Rq1bYJdFFJ8C7gsAPg/OMbXOPk45Cxcbqigk4tDQzjc6LD86zRieynGruW 6leQFMVc+m1In6kN2l+8YA+1atBBggiuMIIH4jCCBcqgAwIBAgIBDTANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGB pH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkw VzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w b2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0 ZXMwDQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP /4H/Bc8FFDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhp cqMr3OyzK3aYGJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyR WTTX6mWSv+TraOwuj3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNh HeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG8 59MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6Gu UcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf 6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIO uAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdC taW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/TyxV/stlehMYID0DCC A8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMAkGBSsO AwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5 MTEyNjAwMzQxM1owIwYJKoZIhvcNAQkEMRYEFHh0tIr4lJhtkk/R9prazwEXAN6bMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBAJh4/G2parra4GsBeW+XZL+P5eF+B3ddT3WMBe7/SMq2y9znZ9UX 3dEh1DxV6BRK8kmIUQ2IU/B91QzzkP1+d4FkuP7jogiiv0OW/ZmT8SRH1X0jJvR/qcPraGaz 6yRfg7Qun1PlOyg6nm+mLvQgUvBntHP8UUU4AYWRerTuR6XI5VbTs0Guw9ZR4IikLc8mPOIv 8OZnb4BVJUPYvq4ffOjaHxz89Uxnd/RugFBb41S9tpgCIcQutXLBNd0eeFdRm6fFDudd0bEw At0mJTAcm2xeTbzATYvEpb7Yn73kTUDhXmMvVX64aEoMWzAPad73/uPEq3muCGMuYS/nq1Tw mGgAAAAAAAA= --------------ms090504020303050901070602-- From yngve@opera.com Wed Nov 25 16:34:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D263A687B for ; Wed, 25 Nov 2009 16:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 m+01ws+4jPXh for ; Wed, 25 Nov 2009 16:34:31 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id B687A3A6843 for ; Wed, 25 Nov 2009 16:34:30 -0800 (PST) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAQ0WlLu020605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Nov 2009 00:32:49 GMT Date: Thu, 26 Nov 2009 01:34:07 +0100 To: "Eric Rescorla" , tls@ietf.org From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20091125223502.4265B6C3285@kilo.networkresonance.com> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20091125223502.4265B6C3285@kilo.networkresonance.com> User-Agent: Opera Mail/9.65 (Win32) Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:34:31 -0000 On Wed, 25 Nov 2009 23:35:02 +0100, Eric Rescorla wrote: > The idea is to use a magic cipher suite to signal that the client can > securely renegotiate (as described in > draft-mrex-tls-secure-renegotiation). However, the server treats this > EXACTLY as if the client had offered an empty RI extension, and > responds with its own RI extension (or if it doesn't implement the > full extension framework, just adds a known byte string to the end of > the ServerHello). In other words: > > > Client Server > ------------------------------------------------------ > ClientHello + TLS_RENEGO_PROTECTION_REQUEST -> > <- ServerHello + Empty RI To me this looks like something that can work. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From mrex@sap.com Wed Nov 25 17:02:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298D33A68B3 for ; Wed, 25 Nov 2009 17:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 jnZP-nsarXDk for ; Wed, 25 Nov 2009 17:02:29 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 265583A67BD for ; Wed, 25 Nov 2009 17:02:28 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQ12LDq022067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 02:02:21 +0100 (MET) From: Martin Rex Message-Id: <200911260102.nAQ12KhK009382@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Thu, 26 Nov 2009 02:02:20 +0100 (MET) In-Reply-To: <20091125232446.24F2A6C32B0@kilo.networkresonance.com> from "Eric Rescorla" at Nov 25, 9 03:24:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 01:02:30 -0000 Eric Rescorla wrote: > > At Wed, 25 Nov 2009 15:19:51 -0800, > Michael D'Errico wrote: > > The complaint I have about sending the verify_data over the wire is > > that that alone does not plug the hole. You need to take the extra > > step to check that it's correct, and a maintenance programmer not > > intimately familiar with TLS might miss this fact. > > I don't find this argument very compelling. There are all sorts of > ways to screw up your TLS implementation that are worse than this > and are difficult/impossible to detect from the other side. E.g., The compelling reason is, that when we define TLSv1.3 then we could stop sending the TLS extension RI entirely for TLS sessions negotiated to use TLSv1.3. If we use the band-aid TLS-extension-RI-with-verify-data to put the verify data from the last handshake into the renegotiation, we will need to contine apply this band-aid eternally. -Martin From pgut001@wintermute01.cs.auckland.ac.nz Wed Nov 25 17:03:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495A43A6843 for ; Wed, 25 Nov 2009 17:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=-0.983, 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 mKS36zilUHiY for ; Wed, 25 Nov 2009 17:03:27 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 78EA13A67BD for ; Wed, 25 Nov 2009 17:03:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 48D0B9DE97; Thu, 26 Nov 2009 14:03:12 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBQTukFblSun; Thu, 26 Nov 2009 14:03:12 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D35F49DE9A; Thu, 26 Nov 2009 14:03:07 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NDSlH-0005i1-IA; Thu, 26 Nov 2009 14:03:07 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NDSlH-0007XG-I7; Thu, 26 Nov 2009 14:03:07 +1300 From: Peter Gutmann To: Pasi.Eronen@nokia.com, tls@ietf.org, yngve@opera.com In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310FE525@NOK-EUMSG-01.mgdnok.nokia.com> Message-Id: Sender: pgut001 Date: Thu, 26 Nov 2009 14:03:07 +1300 Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 01:03:28 -0000 writes: >Although it would be nice if we could just say "everyone SHOULD use TLS 1.2 >(or IPv6, DNSSEC, ...) by end of 2010, and MUST switch off SSLv3 (or IPv4, >NATs, unsigned DNS records, ..) by 2012, that's not something IETF documents >usually say, because it wouldn't have much effect. Just as an extra data point, PKIX documents have occasionally tried this. Pretty much everyone completely ignored it. Peter. From pgut001@wintermute01.cs.auckland.ac.nz Wed Nov 25 17:08:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286253A696E for ; Wed, 25 Nov 2009 17:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=-0.860, 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 lKcVQULaXBa8 for ; Wed, 25 Nov 2009 17:08:47 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 43E163A6948 for ; Wed, 25 Nov 2009 17:08:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 41F629DEC0; Thu, 26 Nov 2009 14:08:42 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TYbgYBjb5V6; Thu, 26 Nov 2009 14:08:42 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 21CBE9DEB7; Thu, 26 Nov 2009 14:08:42 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NDSqg-00062s-GN; Thu, 26 Nov 2009 14:08:42 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NDSqf-0007a4-Vw; Thu, 26 Nov 2009 14:08:42 +1300 From: Peter Gutmann To: yngve@opera.com In-Reply-To: Message-Id: Sender: pgut001 Date: Thu, 26 Nov 2009 14:08:41 +1300 Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 01:08:48 -0000 "Yngve Nysaeter Pettersen" writes: >The reason I was investigating the site was that the EV indication was flip- >flopping on this site, which turned out to be because one certificate had a >1024 bit key (which qualifies for EV), the other was using a 1023 bit key >(which does not qualify for EV). So the CA issued a certificate that it should never have issued? And then the client did more checking than the CA did? Do other implementations perform this level of checking of EV conditions as well, or do they just assume that if the EV flag is set then everything must be OK because the CA says it is? I'd be interested in feedback from on this one (private is OK if you don't feel like making it public). Kinda scary if it's left to the RP to do the CA's work... Peter. From mrex@sap.com Wed Nov 25 17:57:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C163A6778 for ; Wed, 25 Nov 2009 17:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 XgCPW8zl5yro for ; Wed, 25 Nov 2009 17:57:22 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 59F6D3A67BD for ; Wed, 25 Nov 2009 17:57:01 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQ1utiE029906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 02:56:55 +0100 (MET) From: Martin Rex Message-Id: <200911260156.nAQ1usVT012862@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Thu, 26 Nov 2009 02:56:54 +0100 (MET) In-Reply-To: <20091125232446.24F2A6C32B0@kilo.networkresonance.com> from "Eric Rescorla" at Nov 25, 9 03:24:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 01:57:22 -0000 Eric Rescorla wrote: > > At Wed, 25 Nov 2009 15:19:51 -0800, > Michael D'Errico wrote: > > The complaint I have about sending the verify_data over the wire is > > that that alone does not plug the hole. You need to take the extra > > step to check that it's correct, and a maintenance programmer not > > intimately familiar with TLS might miss this fact. > > I don't find this argument very compelling. There are all sorts of > ways to screw up your TLS implementation that are worse than this > and are difficult/impossible to detect from the other side. E.g., > > - Weak randomness > - Failure to check buffers leading to buffer overflows > - Failure to check certs > > TLS relies throughout on the assumption that the other side is > implemented more or less correctly. If we can't count on that, > we have bigger problems than this issue. If I look at the TLS renegotiation vulnerability, then I think the SSLv3 designers who put renegotiation in screwed it up in two ways: - they didn't authenticate the enclosing TLS session in the renegotiation handshake. - they used the exact same algorithm to authenticate initial authentications and renegotiations, and the result is that initial handshake can be proxied into renegotiations. I think that we should not repeat either of these mistakes. -Martin From mrex@sap.com Wed Nov 25 18:04:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C291D3A67F5 for ; Wed, 25 Nov 2009 18:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.277 X-Spam-Level: X-Spam-Status: No, score=-104.277 tagged_above=-999 required=5 tests=[AWL=1.972, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 yv+BBgItir3T for ; Wed, 25 Nov 2009 18:04:38 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 08FFB3A67AF for ; Wed, 25 Nov 2009 18:04:37 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQ24VnK013033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Nov 2009 03:04:31 +0100 (MET) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com From: Internet-Drafts@ietf.org Orig-To: i-d-announce@ietf.org To: tls@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091126010001.83AD43A6848@core3.amsl.com> Date: Wed, 25 Nov 2009 17:00:01 -0800 (PST) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Sender: mrex@sap.com Errors-To: i-d-announce-bounces@ietf.org X-Scanner: Virus Scanner virwal05 X-Scanner: Virus Scanner virwal03 X-SAP: out Subject: [TLS] I-D Action:draft-mrex-tls-secure-renegotiation-01.txt X-BeenThere: tls@ietf.org Reply-To: internet-drafts@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 02:04:41 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transport Layer Security (TLS) Secure Renegotiation Author(s) : M. Rex Filename : draft-mrex-tls-secure-renegotiation-01.txt Pages : 16 Date : 2009-11-25 A protocol design flaw in the TLS renegotiation handshake leaves all currently implemented protocol version of TLS (SSLv3 to TLSv1.2) vulnerable to Man-in-the-Middle (MitM) attacks where the attacker can establish a TLS session with a server, send crafted application data of his choice to the server and then proxy an unsuspecting client's TLS handshake into the TLS renegotiation handshake of the server. Many applications on top of TLS see the data injected by the attacker and the data sent by the client as a single data stream and assume that an authentication during the TLS renegotiation handshake or contained in the client's application data applies to the entire data stream received through the TLS-protected communication channel. This document describes a protocol change for all protocol versions of TLS plus SSLv3 that will fix this vulnerability for all communication between updated TLS clients and updated TLS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mrex-tls-secure-renegotiation-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-mrex-tls-secure-renegotiation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-25165433.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From peter.robinson@rsa.com Wed Nov 25 18:31:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459E83A67EE for ; Wed, 25 Nov 2009 18:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 6omrkOFJ1fG8 for ; Wed, 25 Nov 2009 18:31:41 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 269623A67EB for ; Wed, 25 Nov 2009 18:31:41 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nAQ2VZOB032363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 21:31:35 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 25 Nov 2009 21:31:32 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id nAQ2VW1x004398; Wed, 25 Nov 2009 21:31:32 -0500 Received: from CORPUSMX100B.corp.emc.com ([128.222.76.52]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 21:31:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Nov 2009 21:31:30 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0949_01CA6E94.61843570" Message-ID: In-Reply-To: <20091125223502.4265B6C3285@kilo.networkresonance.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [TLS] Avoiding first use of RI in ClientHello Thread-Index: AcpuH3cgP5jvfIMhRI+TGJGa3V/TtwAIAO6g References: <20091125223502.4265B6C3285@kilo.networkresonance.com> From: To: , X-OriginalArrivalTime: 26 Nov 2009 02:31:32.0286 (UTC) FILETIME=[90FBBDE0:01CA6E40] X-EMM-EM: Active Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 02:31:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0949_01CA6E94.61843570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >What about not putting the verify data in the extension? I prefer this going into the extension. > What do people think about this approach? I think this approach is good. ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. ------=_NextPart_000_0949_01CA6E94.61843570 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWmzCCAucw ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1 s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5 IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3 Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/ eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5 /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1 cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13 qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggR+MIID56ADAgECAhEAsSe9 yNTH2rYKRiN7F8KhkTANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT MB4XDTA5MDcyMTA1MTYxM1oXDTExMDcyMjA1MTYxM1owgekxEzARBgoJkiaJk/IsZAEZFgNjb20x EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjEMMAoGA1UECxMD UlNBMRUwEwYDVQQLEwxBc2lhL1BhY2lmaWMxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQF EwYwNjQ4MTQxFzAVBgoJkiaJk/IsZAEBEwdyb2JpbnAyMRcwFQYDVQQDEw5QZXRlciBSb2JpbnNv bjElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA2CcjIV2QNoJP4YbPejhZX2MSu53/EooTnrkf7M4gsl1DobXkk3CO6kU9bN6O wwL/o87dQ4y2FHjwkV4WeoodhvZa08q5uX4vZCtB2Hn0OUrbPzyKl7wXSq+yezKCQJBrVCTwWjKK A6Gqc1VhkqWSBCpUaQ39TsVDxNYCGIn433cCAwEAAaOCAX8wggF7MIGSBgNVHSAEgYowgYcwgYQG CSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5o dG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9y YXRlZCBieSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnBldGVyLnJvYmluc29uQHJzYS5jb20wDgYDVR0PAQH/BAQDAgeAMEYG A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQm 7p962rS9dUpGeQZt+Vi1su6tQTANBgkqhkiG9w0BAQUFAAOBgQCghPP5wxcDJuACPYJ/U1sjhyE4 gxpGKZNPnnDcjfHo+Cq87cWawpV5Rzpg8KVZc0EoG6BabGNyk+WgZMjCzADpg+appN4cX+DML0ir 3cBcX8pQTuKw1VRlUjidjkTIl/Z2hrcvgh2lJG+PFV2ogWICzwOj4/zKG4khs9VO5NNPezCCBI4w ggP3oAMCAQICEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFS U0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xh c3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czELMAkGA1UEBhMCVVMwHhcNMDkwNzIxMDUxNjE4WhcNMTEwNzIyMDUxMzM2WjCB7TETMBEGCgmS JomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0 aW9uMQwwCgYDVQQLEwNSU0ExFTATBgNVBAsTDEFzaWEvUGFjaWZpYzEUMBIGA1UECxMLRW5naW5l ZXJpbmcxDzANBgNVBAUTBjA2NDgxNDEXMBUGCgmSJomT8ixkAQETB3JvYmlucDIxGzAZBgNVBAMT ElBldGVyIFJvYmluc29uLUVuYzElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqeM4888BmvaveugOJqTYWGNm3cTP6qJe444S 7AJaXDnKZlt1cJByB+B83hdGGe2FyRQGGef0DNZhQIfaa41dzZbDWuogZ3mKxyuOhciZSoRoCIM0 jlPh5vqhDmXBPFQ/EedNPRk+tl+mKVz2fHbsI01bWtueV05BvJu330cj0WUCAwEAAaOCAYswggGH MDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDCB kgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwUwdzAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNl Y3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMC AQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCEGA1UdEQQaMBiBFnBldGVyLnJvYmlu c29uQHJzYS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206 ODAvUlNBQ2xhc3MyUGVyc29uYWxDQS5jcmwwHwYDVR0jBBgwFoAUxpPuxqX+41WOz4ojH+6Y3iHy n6cwHQYDVR0OBBYEFGg/pAQlQSo2dvZeyryhS2toL395MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG 9w0BAQUFAAOBgQCY/nGMkd29x8wULeVsTP+emR/XVn+LqcfwzgwpUSKP1FX1WedrHwlNKFaVDjQX FaNETkV4XzMugf4iafsgZUp5DmzIOBB5H5MI1k+CprZ0tjet7gcN0sdCt0fggfw44GZ37rwxzwyt XZrbEePtb8wFYVEobKBD/ZqvghavL93K3DGCA4EwggN9AgEBMIGiMIGMMRowGAYDVQQKExFSU0Eg U2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3Mg MiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEL MAkGA1UEBhMCVVMCEQCxJ73I1MfatgpGI3sXwqGRMAkGBSsOAwIaBQCgggI0MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTEyNjAyMzEzMFowIwYJKoZIhvcNAQkE MRYEFLPSAYsbTd2bXQ9ed7IthANua2REMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA NRCrNv7LKPSSUf2xnesEONIUY6XyFZkJH20f5tc1h5pujPSif9DefXn+TMhFuZKI0GK5nT0OdvOs bHdcnGdemNC2tI8eoSF5kM5hj7JdAUe2B2tn3ljEYMAXiSJ7259IFtHCGIu2L9C7WTc/c0EjodSj kNsIbc4o2/5Vg3h4UakAAAAAAAA= ------=_NextPart_000_0949_01CA6E94.61843570-- From mrex@sap.com Wed Nov 25 18:36:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B113A67EE for ; Wed, 25 Nov 2009 18:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 LhVp1Go8E-WG for ; Wed, 25 Nov 2009 18:36:33 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id ADEA83A67EB for ; Wed, 25 Nov 2009 18:36:32 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQ2aQk0022632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Nov 2009 03:36:26 +0100 (MET) From: Martin Rex Message-Id: <200911260236.nAQ2aQRg015109@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Thu, 26 Nov 2009 03:36:26 +0100 (MET) In-Reply-To: <20091126010001.83AD43A6848@core3.amsl.com> from "Internet-Drafts@ietf.org" at Nov 25, 9 05:00:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Subject: Re: [TLS] I-D Action:draft-mrex-tls-secure-renegotiation-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 02:36:33 -0000 Internet-Drafts@ietf.org wrote: > > Title : Transport Layer Security (TLS) Secure Renegotiation > Author(s) : M. Rex > Filename : draft-mrex-tls-secure-renegotiation-01.txt > Pages : 16 > Date : 2009-11-25 This is only a cleanup of the description in the document, the design has not changed so far. If we send anything data back S->C trailing the ServerHello instead of modifying existing fields, then this _ought_ to be encoded like a real TLS extension (though SSLv3 Server might be stuffing it in as a fixed blob. C->S signaling with magic ciphersuite and S->C signaling with an empty extension RI on initial and renegotiation handshake and allowing (but _not_ requiring) extension RI in ClientHello when other extensions are sent is something I could live with. I would really appreciate feedback from implementors, in particular those who haven't been actively participating this discussion (yet), whether/where they see problems with their installed base on these questions: ? issue with TLS extensions in ClientHello (renegotiation handshake) ? issue with (single) TLS extension in ServerHello ? issue with TLS extensions in general Anyone whos making SSL-aware loadbalancers/NATs or SSL accelerators? Or stuff similar to the JetDirect network print server -- very little of such equipment ever sees a firmware update in its lifetime. -Martin From huangmin@huaweisymantec.com Wed Nov 25 18:44:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23533A6938 for ; Wed, 25 Nov 2009 18:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLr5owssBlud for ; Wed, 25 Nov 2009 18:44:47 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 171F03A6877 for ; Wed, 25 Nov 2009 18:44:47 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTP00JTY3M7PN90@hstga02-in.huaweisymantec.com> for tls@ietf.org; Thu, 26 Nov 2009 10:44:31 +0800 (CST) Received: from h00104745 ([10.27.154.97]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KTP00G3S3M75U10@hstml01-in.huaweisymantec.com> for tls@ietf.org; Thu, 26 Nov 2009 10:44:31 +0800 (CST) From: Min Huang To: 'Eric Rescorla' Date: Thu, 26 Nov 2009 10:44:30 +0800 Message-id: <001f01ca6e42$6179f580$619a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcpuQmEJ8hD5CuVdS3m02GbF+05ZwA== Cc: tls@ietf.org Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 02:44:48 -0000 At Wed, 25 Nov 2009 16:05:53 -0800 Eric Rescorla wrote: ... >> The whole idea that extensions are rare just doesn't match with >> today's reality. Yes, there are some implementations that can't handle them. >> That is a very small percentage compared to the number of >> implementations that can't safely renegotiate (e.i. 100% of them). >> Those implementations already have to deal with a world in which >> extensions are real and common. They also have to deal with a world in >> which their code will need to be patched in order to be safe anyway. >> ... >I'd be very interested in seeing data on what fraction of existing servers can't handle extensions. Is there any chance that you have measurements? I am very interested in the statistical data of extensions supporting in the real running Internet, too. It will be meaningful when people discuss whether extension is used to solve the vulnerability. regards, Min Huang From djhopwood@googlemail.com Wed Nov 25 19:09:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1403A6993 for ; Wed, 25 Nov 2009 19:09:16 -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 H3fpCxJmttEs for ; Wed, 25 Nov 2009 19:09:15 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 4A7773A697C for ; Wed, 25 Nov 2009 19:09:15 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so98108eyf.51 for ; Wed, 25 Nov 2009 19:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=XH905v99yMR4bF6R6p0aCXz4nVNYHnRniyGWdj2CLKk=; b=xs9QEXvlpFqo9tkElA7o6DQO6ETkDiH7LgoasvqZXq2JbaPiZ9j03UMbQ0+DmE0EmK Ehsr9RUWX1sGwGOfdQRMTMoUxtn4F2Q/B3X7K9gvN+513btSBnEaYv6351sCeTrpvQPd 6dMNQoVQGPKfzZbT2wu3n+iLzG2TzQvjMYd7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=sn4hWwR7G6E9Yfr3DlH6+HP58igMhSL4D3HCL2MnmVlh/TxWyXI0spbQ9uSTqihaoT iFwl1Z/DtaVRpI90SRXH3r3QCgvnwnR5yHitx2szTSlwcPkHi92l3kQzsqRyOIuzt2OG P63q4L2b/oxnetEULhTXFkYVp95m7S/px+ZSE= Received: by 10.213.23.155 with SMTP id r27mr8759648ebb.25.1259204947047; Wed, 25 Nov 2009 19:09:07 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 28sm497887eyg.4.2009.11.25.19.09.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 19:09:06 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0DF154.8040702@jacaranda.org> Date: Thu, 26 Nov 2009 03:09:08 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911251812.nAPIChHs011010@fs4113.wdf.sap.corp> In-Reply-To: <200911251812.nAPIChHs011010@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7D74465D63A1606D5F6D0993" Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 03:09:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7D74465D63A1606D5F6D0993 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Michael D'Errico wrote: >> The proposed change (empty extension in both directions on every >> handshake + incorporate previous verify_data into new Finished) has >> some nice benefits over the current RI proposal: >=20 > The are currently TLS servers that will send back unsolicited > TLS extensions to the client if a particular ciphersuite (a real one) > is selected. They should stop doing that. RFC 4366 section 2.3: # Note that for all extension types (including those defined in the # future), the extension type MUST NOT appear in the extended server # hello unless the same extension type appeared in the corresponding # client hello. Thus clients MUST abort the handshake if they receive # an extension type in the extended server hello that they did not # request in the associated (extended) client hello. Notice that not only are these servers nonconformant, any client that does not abort the handshake in response is *also* nonconformant. > It's funny that WinXP/Win2003, although not able or willing to > send TLS extensions in ClientHello, do not seem to barf on > unsolicited ServerHelloExtensions in the server's reply, > and instead make it somehow available for the Cryptographic > Service Provider. What part of "Thus clients MUST abort the handshake..." do they not understand? --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig7D74465D63A1606D5F6D0993 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksN8VsACgkQWUc8YzyzqAc8lQD/X93fRWt7xsUTArBJKeQAP6fg ZZPP+LTOIhBvfjrdVM4A/AqTLio97fNR3qsmcLJdEIXB9AVHeK20UIEIUPT8y3OU =60uc -----END PGP SIGNATURE----- --------------enig7D74465D63A1606D5F6D0993-- From mike-list@pobox.com Wed Nov 25 19:49:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E723A699C for ; Wed, 25 Nov 2009 19:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 KduKRGmYSMvX for ; Wed, 25 Nov 2009 19:49:13 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id B79C73A6971 for ; Wed, 25 Nov 2009 19:49:13 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7EFCBA144B for ; Wed, 25 Nov 2009 22:49:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=wZ1PPe1xyDwO LRXQhaWs5cOp0jE=; b=UTJytUdWlsbgVGwnRR2iF3wOVuwsvEqBarmYjkq/5sNJ 9IECievAGExRkG2JJRftyLx7t+MyLEp8zWQYlvp+zUwZlGdUMTYrnFL9Kcw5UnWl DtDVKcgBIKO8ztoNPclwe0J0CiqqKWUcZg8d9fhTO/kqiWOuSvjR8QlMrz0J1N0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=JIsRZa 19Lq/8cp36VYQizodqW4LHv2qpe7vK03Ms9vu8Fx4bE2E0ehmgTp/u/HHTDtfqOH x1o8lqhN7p9qh/rBI9D4WhysBO+ejXksbj/f+HfW54LDB1CwgN9787cyBff0AxyH HiXaWpgg6siLRPZZ1mP7oNTBJdXDaEUqnLUQU= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7B4A0A144A for ; Wed, 25 Nov 2009 22:49:08 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 1FAD0A1446 for ; Wed, 25 Nov 2009 22:49:07 -0500 (EST) Message-ID: <4B0DFB03.5020201@pobox.com> Date: Wed, 25 Nov 2009 19:50:27 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Working Group References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <4B0DBB97.5050500@pobox.com> In-Reply-To: <4B0DBB97.5050500@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: A68A7FE2-DA3E-11DE-A8CF-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 03:49:14 -0000 > Eric Rescorla wrote: > >>> 3) Incorporate previous verify_data into Finished calc. >> >> I'm not happy with this, actually. Would this work: Finished = verify_data XOR previous_verify_data Not sure if anyone has suggested that already.... Does it work if you renegotiate twice or more times? Also how to handle if renegotiation changes TLS version (SSLv3 verify_data is 36 bytes long). Mike From yangqinqin@huaweisymantec.com Wed Nov 25 19:55:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472A73A69CB for ; Wed, 25 Nov 2009 19:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.189 X-Spam-Level: ** X-Spam-Status: No, score=2.189 tagged_above=-999 required=5 tests=[AWL=2.684, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 745kTDystIu5 for ; Wed, 25 Nov 2009 19:55:36 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 4A7D83A6971 for ; Wed, 25 Nov 2009 19:55:36 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=iso-8859-1 Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTP0098D6W88X10@hstga01-in.huaweisymantec.com> for TLS@ietf.org; Thu, 26 Nov 2009 11:55:20 +0800 (CST) Received: from y00144023 ([10.27.154.91]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KTP00K7R6W7U610@hstml01-in.huaweisymantec.com> for TLS@ietf.org; Thu, 26 Nov 2009 11:55:20 +0800 (CST) Message-id: <09fb01ca6e4c$45f93410$5b9a1b0a@china.huawei.com> From: yangqinqin To: Bruno Harbulot References: <200911251724.nAPHOMf2007151@fs4113.wdf.sap.corp> <4B0D6A7B.1040803@extendedsubset.com> Date: Thu, 26 Nov 2009 11:55:19 +0800 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 03:55:37 -0000 >Bruno Harbulot wrote: > >Marsh Ray wrote: >> Martin Rex wrote: >>> I'm actually very favourable of a restriction that already established >> >identities (not the lack thereof!) must not change during renegotiaton, >>> and contemplating to add this into my proposal as well. > > > >I believe the current TLS specs do not have a sufficiently rigorous > >definition of "identity" in order to be mandating restrictions like > this. memcmp() of certs doesn't cut it. At best, they will be ignored. >> At worst, they will entice developers to make unsafe assumptions. >(Apologies for jumping in this discussion, I have only been able to read some of the e-mails posted on this list this month.) >I think the TLS spec should stay away from the concept of identity. This >is too vague a concept and people have different expectations for it. >It's more appropriate in something like PKIX. >Some certificate-based mechanisms do not necessarily rely on the concept >of user identity (in the sense of certificate = user). >One could imagine a situation where a client would initially present a >client certificate that contains attributes (like an attribute >certificate), but that doesn't embed the attributes the server wants for >this particular request. The server could then initiate a re-negotiation >to ask the client to present another certificate, with other attributes. >This can be particularly useful for role-based (or virtual organisation) >authorisation, for example. >The concept of identity then becomes rather loose; in some contexts, >anonymity might even be required. >I don't think that TLS should address this; rather, it should be up to >the components that verify the certificates. I agreed that the concept of identity is too vague a concept and people have different expectations for it. And a client can have several different client certificates that contains attributes, particularly, for role-based authorization. So I think that TLS should allow such identity changes during renegotiation. Pasi wrote: >For the TLS library, the only form of identity comparison it can do is >memcmp(), since all the rest depends on what semantics the >applications give to various fields in the certificate (subject, >subjectAltName, NameConstraints, Clearance, CertificatePolicies, >etc.). But if the application wants to do more complex identity >comparison, it can do so. For identity comparison during renegotiation,TLS may only do memcmp() , and more complex identity comparison can be left to Specific application to do. There shloud have a alarm message to applications and leave applications to choose whether to continue re-negotiation. Best regards, Qinqin Yang From mrex@sap.com Wed Nov 25 19:57:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8192F3A6986 for ; Wed, 25 Nov 2009 19:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.171 X-Spam-Level: X-Spam-Status: No, score=-7.171 tagged_above=-999 required=5 tests=[AWL=1.078, BAYES_00=-2.599, GB_I_LETTER=-2, 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 qHa6LA31cgsS for ; Wed, 25 Nov 2009 19:57:10 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 401C53A6971 for ; Wed, 25 Nov 2009 19:57:10 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQ3v3B3004022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 04:57:03 +0100 (MET) From: Martin Rex Message-Id: <200911260357.nAQ3v36A020311@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 26 Nov 2009 04:57:03 +0100 (MET) In-Reply-To: <4B0DF154.8040702@jacaranda.org> from "David-Sarah Hopwood" at Nov 26, 9 03:09:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 03:57:11 -0000 David-Sarah Hopwood wrote: > > Martin Rex wrote: > > > > The are currently TLS servers that will send back unsolicited > > TLS extensions to the client if a particular ciphersuite (a real one) > > is selected. > > They should stop doing that. Not necessarily -- if they really think they need that extension being sent back, then they really OUGHT to write it explicitly into their spec (I-D). > RFC 4366 section 2.3: > > # Note that for all extension types (including those defined in the > # future), the extension type MUST NOT appear in the extended server > # hello unless the same extension type appeared in the corresponding > # client hello. Thus clients MUST abort the handshake if they receive > # an extension type in the extended server hello that they did not > # request in the associated (extended) client hello. > > Notice that not only are these servers nonconformant, any client that > does not abort the handshake in response is *also* nonconformant. That is an obvious defect in rfc4366, because it is too strict. Even EKR has recently been recently commenting that the wording of the spec is imperfect and what is more important is the intent. : : What about 5246 and unsolicited extensions? : As far as I can tell, the major argument against using extensions : for S->C signalling is the 5246 prohibition against the server providing : unsolicited extensions. However, that was clearly intended to prevent : the server from sending extensions the client didn't expect and : that's not the case here. Moreover, we're updating 5246 so we can relax : the restriction for this extension (though I would think not in general). If you've been following the discussion about if and how the changing of identities during renegotiation should be locked down, then you get an idea how difficult it is to specify a restriction in a fashion that it does not get in the way of inventions and engineering. The idea behind the TLS extensions is that they need to be negotiated before they can be used, otherwise there is no agreement that an option be used. This means that in general there is a problem if the server is the first to mention an Extension, because it lacks the confirmation from the client. What the writers of that text did not address is the possibility that the information from the client to the server might have been implied by some other option supplied by the client -- like a cipher suite for example (and there may be real world constraints why the client was not able to propose the TLS extension himself in ClientHello, maybe because it is a Crypto Service Provider on WinXP/Win2K3 talking TLS through schannel). Anyway -- the ugliness with TLS extension was officially started in rfc-5246 with the semantics of the "signature_algorithm" extension. Not sending it back in the ServerHello is a bad idea. ClientHello and ServerHello is the place where all the crypto parameter negotiation is supposed to happen during the TLS handshake, and this is where the restriction comes from that one MUST not start the negotiation on the server side in ServerHello. If you think that specs are always perfect, always right and must be followed by the letter, then you know little about specs. There is no software without a bug and no spec without a defect. And people who have problem applying common sense to specs are usually buerocrats, not engineers. > > It's funny that WinXP/Win2003, although not able or willing to > > send TLS extensions in ClientHello, do not seem to barf on > > unsolicited ServerHelloExtensions in the server's reply, > > and instead make it somehow available for the Cryptographic > > Service Provider. > > What part of "Thus clients MUST abort the handshake..." do they not > understand? Pardon me, but that is a pretty bold requirement which deserves to be ignored when common sense calls for it. I hear a lot of people complaining about extensions-intolerant SSLv3 servers, because they close the connection when receiving something that they do not understand. Had the rules for TLS extension been set defined with more common sense describing the intent, then it should have been obvious that chopping up the signature_algorithms extension is a bad idea. -Martin From yangqinqin@huaweisymantec.com Wed Nov 25 20:32:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B867A3A696A for ; Wed, 25 Nov 2009 20:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.961 X-Spam-Level: * X-Spam-Status: No, score=1.961 tagged_above=-999 required=5 tests=[AWL=1.571, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9LQUFSTNkS6 for ; Wed, 25 Nov 2009 20:32:05 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id A24283A683D for ; Wed, 25 Nov 2009 20:32:04 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_biWWQHms3/v26FObdGXpww)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTP009PA8L08X10@hstga01-in.huaweisymantec.com> for TLS@ietf.org; Thu, 26 Nov 2009 12:31:48 +0800 (CST) Received: from y00144023 ([10.27.154.91]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KTP00LAC8KZ1P10@hstml01-in.huaweisymantec.com> for TLS@ietf.org; Thu, 26 Nov 2009 12:31:48 +0800 (CST) Message-id: <0a4701ca6e51$5e1f33f0$5b9a1b0a@china.huawei.com> From: yangqinqin To: mrex@sap.com, Eric Rescorla References: <200911251724.nAPHOMf2007151@fs4113.wdf.sap.corp> Date: Thu, 26 Nov 2009 12:31:47 +0800 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 04:32:06 -0000 This is a multi-part message in MIME format. --Boundary_(ID_biWWQHms3/v26FObdGXpww) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Nico wrote: >On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote: >> Personally, I would it find much cleaner if the semantics for the >> renegotiation would require the TLS peers to suspend transmission >> of application data while performing TLS renegotiation, >> i.e. >+1 >This is the right time to add such a constraint. >Unlike a "authenticated identities can't change" constraint, this could >be implemented without conceivable app protocols being broken, I think, >but it may require API changes for some implementations, and that it may >put this change out of reach.+1I agree to add such a constraint in this draft. ----- Original Message ----- From: Martin Rex To: Eric Rescorla Cc: TLS@ietf.org Sent: Thursday, November 26, 2009 1:24 AM Subject: Re: [TLS] some questions for your draft I'm actually very favourable of a restriction that already established identities (not the lack thereof!) must not change during renegotiaton, and contemplating to add this into my proposal as well. http://www.ietf.org/mail-archive/web/tls/current/msg04136.html http://www.ietf.org/mail-archive/web/tls/current/msg04132.html http://www.ietf.org/mail-archive/web/tls/current/msg04091.html -Martin Eric Rescorla wrote: > > At Wed, 25 Nov 2009 10:44:35 -0600, > Marsh Ray wrote: > > > > yangqinqin wrote: > > > Marsh, > > > > > > Thank you for your reply. I have just joined the mailing list. > > > > > > In your draft, "If the other end attempts to authenticate with a > > > different identity, the renegotiation MUST fail." > > > > > > How do you achieve it in the renegotiation? > > > > > > You also wrote in the draft, "For certificate based cipher suites, > > > this means bitwise equality of the end-entity certificate. " > > > > > > This increases authentication steps. But original TLS renegotiation > > > protocol has not this step. > > > > > > Yeah, I don't know how that got in there. > > > > I certainly didn't put it in, and I do not think it has any place in the > > TLS spec. > > As I said, Pasi Eronen suggested it and it seemed sound to me. > > I'm not wedded to it and if the WG feels that it's a bad idea, I'll > gladly take it out. Pasi? _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --Boundary_(ID_biWWQHms3/v26FObdGXpww) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
 

Nico wrote:

>On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote:


>> Personally, I would it find much cleaner if the semantics for the
>> renegotiation would require the TLS peers to suspend transmission
>> of application data while performing TLS renegotiation,
>> i.e.

>+1

>This is the right time to add such a constraint.

>Unlike a "authenticated identities can't change" constraint, this could
>be implemented without conceivable app protocols being broken, I think,
>but it may require API changes for some implementations, and that it may
>put this change out of reach.
+1
I agree to add such a constraint in this draft.

----- Original Message -----
From: Martin Rex
Sent: Thursday, November 26, 2009 1:24 AM
Subject: Re: [TLS] some questions for your draft


I'm actually very favourable of a restriction that already established
identities (not the lack thereof!) must not change during renegotiaton,
and contemplating to add this into my proposal as well.


http://www.ietf.org/mail-archive/web/tls/current/msg04136.html
http://www.ietf.org/mail-archive/web/tls/current/msg04132.html
http://www.ietf.org/mail-archive/web/tls/current/msg04091.html

-Martin

Eric Rescorla wrote:
>
> At Wed, 25 Nov 2009 10:44:35 -0600,
> Marsh Ray wrote:
> >
> > yangqinqin wrote:
> > > Marsh,
> > >
> > > Thank you for your reply. I have just joined the mailing list.
> > >
> > > In your draft, "If the other end attempts to authenticate with a
> > > different identity, the renegotiation MUST fail."
> > >
> > > How do you achieve it in the renegotiation?
> > >
> > > You also wrote in the draft,  "For certificate based cipher suites,
> > > this means bitwise equality of the end-entity certificate. "
> > >
> > > This increases authentication steps. But original TLS renegotiation
> > > protocol has not this step.
> >
> >
> > Yeah, I don't know how that got in there.
> >
> > I certainly didn't put it in, and I do not think it has any place in the
> > TLS spec.
>
> As I said, Pasi Eronen suggested it and it seemed sound to me.
>
> I'm not wedded to it and if the WG feels that it's a bad idea, I'll
> gladly take it out. Pasi?
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--Boundary_(ID_biWWQHms3/v26FObdGXpww)-- From djhopwood@googlemail.com Wed Nov 25 21:15:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06D93A6903 for ; Wed, 25 Nov 2009 21:15:45 -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 Aq1agTX1chBY for ; Wed, 25 Nov 2009 21:15:44 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 21D993A69BE for ; Wed, 25 Nov 2009 21:15:43 -0800 (PST) Received: by ewy6 with SMTP id 6so431976ewy.29 for ; Wed, 25 Nov 2009 21:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Cw5Gk2MQ0jowKaX6RGoJ5C4Pd689zkpjCDPCIkcIC3M=; b=cdzFEtHi8+yDz+wVvOsL40RoThfUYLA9p+DJDLExF4TdcW3wKESEVCGvoFKm57YGZU ejKA8N0jS4ShPIiq2mrOkO1qDPF71jrQpzpmAEyOTKJybdSGsDo5dkGo6jsz7R3PutZU GrtnzOFcPnR7SH7Z3tlqS8ha+7BGUIBhu8W+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=tlAIvyEmMtEGG+vHXCd2u9eMi2duJdMLERRWwXCQOiFm6eoYUomCtwMpbb3anfH3IY o4eXGRomfhF81e7h+0RRJCV3R00EBRoWsZD3RlxA2IO1Rkvc53PP36+sKX2VZ6Tnnmmj 0dW8q6utBphQ9+nrgPrg5oAeT99nwfp/UpSwk= Received: by 10.216.86.193 with SMTP id w43mr155754wee.17.1259212534580; Wed, 25 Nov 2009 21:15:34 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 28sm4042941eye.7.2009.11.25.21.15.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 21:15:33 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0E0EF4.7000102@jacaranda.org> Date: Thu, 26 Nov 2009 05:15:32 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0D9B94.9080205@pobox.com> In-Reply-To: <4B0D9B94.9080205@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC9D70B015DC09DA69DB5E3A4" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 05:15:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9D70B015DC09DA69DB5E3A4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > I think that it would be good to find a unified solution that > everybody is happy with, and believe that this may be it: >=20 >=20 > 1) Client-to-Server signalling can be done in either of > two ways: >=20 > A) an empty Secure_Renegotiation (SR) extension, or > B) a "magic" cipher suite >=20 > 2) Server-to-Client signal is always an empty SR extension >=20 > 3) Incorporate previous verify_data into Finished calc. >=20 >=20 > The particulars: >=20 > A client that currently sends any other extensions MUST also > send the empty SR extension. >=20 > A client that currently does not send any extensions MAY send > the empty SR extension, or MAY send the magic cipher suite. >=20 > In response to either 1A or 1B, the server responds with an > empty SR extension. The only ugliness is this apparently- > unsolicited extension returned by the server in response to > the magic cipher suite. I used to be against this, but have > since decided that it is no more ugly than flipping a version > bit or any of the other ideas. I fully support this approach. The extension is not really "unsolicited" in this case. > It remains to be decided if adding the verify_data to the > handshake message stream is the right way to do (3), or if > changing the PRF in some way is better, such as changing the > seed to be the handshake message hash appended with the old > verify_data, or some other method. I previously argued for changing the use of the PRF in the Finished computation, mainly in order to ensure that the possible PRF inputs for modified and unmodified Finished computations would be disjoint. However, that would have the disadvantage (pointed out by Bodo M=C3=B6lle= r) that the data signed in any CertificateVerify message wouldn't include the old verify_data, unless that were also explicitly changed. The old verify_data should not just be appended to the handshake_messages= without any further encoding, though, because it might match the bytes of some valid handshake message. In that case, there is the possibility that a MITM might insert the old verify_data into the stream sent to one peer, as though it were a handshake message. If that peer is using the unmodified Finished computation (either because it is unpatched or it is doing an initial handshake), then it may end up computing the same Finished hash as the other peer that is using the modified computation. I haven't gone through the details of this attack thoroughly enough to be sure it will work, but it is too near working for comfort. So, we could either: 1. Change the use of the PRF and also change CertificateVerify (if used): verify_data =3D PRF(master_secret, finished_label, Hash(handshake_messages) + previous_verify_data) [0..verify_data_length-1]; struct { digitally-signed struct { opaque handshake_messages[handshake_messages_length]; switch (is_renegotiation) { case false: struct {}; case true: opaque previous_verify_data[previous_verify_data_length= ]; }; } } CertificateVerify; 2. Add the old verify_data to handshake_messages preceded by the encoding= of a fatal alert. Then, attacks of the kind described above can't work= because the unpatched peer would first process the alert and abort the= handshake. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigC9D70B015DC09DA69DB5E3A4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksODv4ACgkQWUc8YzyzqAc3MwEAkBOpKw/D6UhJznXnvx+JIgmF DjvdIabUE8MGR3JTVTUBAIGTj/2l5CVJq2mX/1XmUUGfNur2+XfQ27oXhD8xhwtu =TOYW -----END PGP SIGNATURE----- --------------enigC9D70B015DC09DA69DB5E3A4-- From djhopwood@googlemail.com Wed Nov 25 21:35:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4103A680F for ; Wed, 25 Nov 2009 21:35:25 -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 Z5fkDhNhxV7T for ; Wed, 25 Nov 2009 21:35:24 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 4D0283A6923 for ; Wed, 25 Nov 2009 21:35:24 -0800 (PST) Received: by ewy6 with SMTP id 6so439214ewy.29 for ; Wed, 25 Nov 2009 21:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=ZC++eX7d0zDn23Tsq9NyQUouDpa3BxA9fzxfIHQ8a/8=; b=bxVOXR2t2ur2wewqVS3/AUaT6kMQv7noXXSzazOEp8MI1Jjs/0wjx0x/z9OB/NcJEq wtgau+xCtbL5MgzkF+cOQ3hDckzNINro+Ho7LgNGswJJMyFp8ctpGuHywnwDMcetr89U ztxNC5aDVH2Ui8/hVNMPPQPhwtrwR5n0hH8tg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=L1cYuSb5SXXLz0Fl35I4MIDCJF4E0hSxnzOkPq3fnCfUE75hn+q67KmNb6m5l+v8mu eNaaBwOCiH30CC940D5YoDfsX515e1obESF36XzXj1qFPtd9oUvr4Yb0qh2a9S8MN+jj ekXETnmGfKH8ph2I3yTETqdoBFi7mWzyaM1jg= Received: by 10.213.100.168 with SMTP id y40mr4347611ebn.77.1259213713123; Wed, 25 Nov 2009 21:35:13 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 16sm168635ewy.14.2009.11.25.21.35.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 21:35:12 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0E1399.8030303@jacaranda.org> Date: Thu, 26 Nov 2009 05:35:21 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> In-Reply-To: <20091125225408.42FB96C3288@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 05:35:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Eric Rescorla wrote: > At Wed, 25 Nov 2009 13:03:16 -0800, > Michael D'Errico wrote: >> I think that it would be good to find a unified solution that >> everybody is happy with, and believe that this may be it: > > This was actually suggested by Bodo Moeller last week. > >> 1) Client-to-Server signalling can be done in either of >> two ways: >> >> A) an empty Secure_Renegotiation (SR) extension, or >> B) a "magic" cipher suite >> >> 2) Server-to-Client signal is always an empty SR extension > > I just sent a message suggesting 1 and almost 2. > >> 3) Incorporate previous verify_data into Finished calc. > > I'm not happy with this, actually. > > This requires breaking the current clean definition of handshake > hashes as the hash of all the handshake messages and simply adding > some synthetic message in the middle. I don't think this is anywhere > near as clean, as evidenced by the ongoing debate about whether to put > it the synthetic data in the front, the back, incorporate it into the > PRF, or chain the pre-existing handshake messages. [FWIW, I think I > prefer the last of these implicit versions.] > > By contrast, RI allows that part of the system (which is well > understood) to remain the same and in fact when RI is offered on the > first handshake, there is no change to the TLS core at all. It's all > just hashed into Finished as part of the ordinary TLS procedures, > and everything is in fact compliant TLS, which I think is desirable. This approach and RI have different security properties: because RI does not change the Finished computation, it relies on the recipient of the extension checking that its contents are correct. OTOH, I think it's only necessary for the previous verify_data to be sent once. So, how about sending that only in the ServerHello, i.e. 1) Client-to-Server signalling: MUST send a "magic" cipher suite MAY send an empty Secure_Renegotiation (SR) extension (and SHOULD do so if it is sending other extensions). 2) Server-to-Client signal MUST be a Secure_Renegotiation extension containing the previous client and server verify_data. A patched client MUST check this value. 3) No change to Finished computation. 4) A server that is doing a renegotiation MUST reject connections from clients that don't include the magic cipher suite. - -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksOE5cACgkQWUc8YzyzqAdUdQD/TiKDPFoe+drbNkjUJvlHpSwA +KE98pvwswuhTaS6xasBAIC6+qQHRRKZ3ZJgf2j6LtE9JqhpFOMJqng73yFwB4tB =LRBo -----END PGP SIGNATURE----- From djhopwood@googlemail.com Wed Nov 25 21:41:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0073A69D1 for ; Wed, 25 Nov 2009 21:41:25 -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 3lS2X-gBN8Ip for ; Wed, 25 Nov 2009 21:41:24 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 8E3213A67B2 for ; Wed, 25 Nov 2009 21:41:24 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so111602eyf.51 for ; Wed, 25 Nov 2009 21:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=jqry0BdOoVBE5dstmaZpGFfQ9CqFkhTAIx8N6UlSd7Y=; b=xGtEv6ozL1jeLbDzdgKHfvSOpiFDhop8DFK03ZZ4FFj77y+K97vd0JbUg0YjAftm/P yKsYl9HWdE6LPWO8RVtz0asLGkxBK/Yl+5O0xxzPP/KghQwQVPNCsAZIdiyrzSx8lF4z OfUazKI3xssGBle4+nJRCHaQwwzAYRrCD0I7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=qdQPX/oTGib4TalCo9jxOJ9qvFfx/F5LKJjwMzFxh8oyh+5NUz1K7v6nPBd1o0F+XA THVk5fCcyc3x9LCcwAua6Sh3CWqQUv1NltayF2wtWd7wxfmS4wbRaiNKoyIBIlOR105j Z5qtmUZDPMHGmzVl37pD3PhDXVPxubAtNpgnY= Received: by 10.213.24.9 with SMTP id t9mr406735ebb.92.1259214073424; Wed, 25 Nov 2009 21:41:13 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 16sm172193ewy.2.2009.11.25.21.41.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 21:41:12 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0E1501.5080002@jacaranda.org> Date: Thu, 26 Nov 2009 05:41:21 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <4B0DBB97.5050500@pobox.com> <4B0DFB03.5020201@pobox.com> In-Reply-To: <4B0DFB03.5020201@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig710AB5051128A1A924273383" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 05:41:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig710AB5051128A1A924273383 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: >> Eric Rescorla wrote: >> >>>> 3) Incorporate previous verify_data into Finished calc. >>> >>> I'm not happy with this, actually. >=20 > Would this work: >=20 > Finished =3D verify_data XOR previous_verify_data No. The previous_verify_data has to be in the input to the PRF that also depends on the master_secret. If you just XOR it to the output, then the attacker doesn't need to know the master_secret in order to change the unmodified Finished to the modified one. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig710AB5051128A1A924273383 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksOFQEACgkQWUc8YzyzqAczqQD/b52/NmduudQRHsDJTAzlBUHN 3OzsvAJanSsvLfI7akcA/0ZxNPWdawGUXNvZgSsZ/US9vR7jx8NtY9EwwEzyZPlf =F9r4 -----END PGP SIGNATURE----- --------------enig710AB5051128A1A924273383-- From n.mavrogiannopoulos@gmail.com Wed Nov 25 21:43:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD863A67F6 for ; Wed, 25 Nov 2009 21:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_11=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkqQT8yzBNOr for ; Wed, 25 Nov 2009 21:43:48 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 2CC883A67B2 for ; Wed, 25 Nov 2009 21:43:47 -0800 (PST) Received: by ewy6 with SMTP id 6so442097ewy.29 for ; Wed, 25 Nov 2009 21:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=i3VWoPGRSYlo13KGq/ZqE4b8I8Pi6LA8DxDgPtzWfmo=; b=ZqS9QIxskMGK7KKW9lWiU2zXIo4BDZuHrIz3j7PMbZX/jIGxlgdgOrSPSGewkHflGg gSxvpuzzA69jjziGRh5NS6lgvmdGi/oAFM3kssHF7W546kyX8cUzmkhGiqbJfEFdJtfa KStZ50Ah3GHs/3i8iRKdAZUB2KxPvlrsgGOfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IP4cRishDAbmMoBS6oo3FIVFnu0PrPyfhQpx6d8u8a41CKf339lQ+cjbFHbcgHWkEY 43RLpYnBx22ny8vSsZWgwjKB0/WKjNMVDJ8HvQDiuGEk25FpNLiMtjeZiSI5h+cVteM4 K+zDtL4E69O8j642Q73hr5+oGPX+5SIpDzgfk= MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.213.23.75 with SMTP id q11mr779211ebb.43.1259214219772; Wed, 25 Nov 2009 21:43:39 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Nov 2009 07:43:39 +0200 X-Google-Sender-Auth: 2283e1badc273b76 Message-ID: From: Nikos Mavrogiannopoulos To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 05:43:49 -0000 On Fri, Nov 20, 2009 at 11:53 PM, Joseph Salowey (jsalowey) wrote: > We have had a lot of good discussion on this list, but I think we need > to start converging on a solution. As I said in a previous message, I've > asked Eric to serve as editor for the WG draft and he has posted > draft-ietf-tls-renegotiation-00 as a starting point. =A0I realize that > there are a number of people who aren't happy with aspects of the draft, > or indeed with the draft as a whole, but I'd like to get the sense for > the feelings of the group as a whole. If we have rough consensus that > this is a workable approach, we can try to nail down the remaining > issues and move forward. > > To try to keep this concrete, please respond with answers to this > question: I support this draft. I am against the alternative non-extension based implementation for the following reason. Such solutions, since they are hacks that just flip existing logic to do something unexpected, will have to carried on indefinitely in implementations. If TLS 1.3 solves this elegantly we'll have two codes that solve this problem, one for TLS 1.x, x<=3D2 and another one for TLS 1.x, x>2. In the long run I don't think that such solutions are good. Of course it is easier to implement today for some but I think will turn against implementation sanity in the end. Given today's trend of the servername extension, is it so important to talk about an non-extension fix? How big is that target group today? Is there a figure? regards, Nikos From mrex@sap.com Wed Nov 25 21:46:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D9B3A6B54 for ; Wed, 25 Nov 2009 21:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 c8xVGp+sKdqc for ; Wed, 25 Nov 2009 21:46:11 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2DA5F3A68AC for ; Wed, 25 Nov 2009 21:46:09 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQ5k26J025592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 06:46:02 +0100 (MET) From: Martin Rex Message-Id: <200911260546.nAQ5k2Rt027106@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 26 Nov 2009 06:46:02 +0100 (MET) In-Reply-To: <4B0E1399.8030303@jacaranda.org> from "David-Sarah Hopwood" at Nov 26, 9 05:35:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 05:46:11 -0000 David-Sarah Hopwood wrote: > > This approach and RI have different security properties: because RI > does not change the Finished computation, it relies on the recipient > of the extension checking that its contents are correct. > > OTOH, I think it's only necessary for the previous verify_data to > be sent once. So, how about sending that only in the ServerHello, i.e. That is MUCH worse. Normally the TLS handshake is symmetric, each one proves each other (like with the Finished messages). Client re-sending Client.Finished and Server re-sending Server.Finished would still be symmetric (and both need to check). If only one side sends and the other must check, then this is asymmetric, and if the one side that is supposed to check forgets it, then you have a security problem. When each one resends. then both must forget to check to make that security problem. -Martin From mrex@sap.com Wed Nov 25 21:50:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4703A69DE for ; Wed, 25 Nov 2009 21:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 gflkg9yvzBpR for ; Wed, 25 Nov 2009 21:50:25 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D92D93A6961 for ; Wed, 25 Nov 2009 21:50:24 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQ5oINb027784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 06:50:18 +0100 (MET) From: Martin Rex Message-Id: <200911260550.nAQ5oID8027283@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 26 Nov 2009 06:50:18 +0100 (MET) In-Reply-To: <4B0E0EF4.7000102@jacaranda.org> from "David-Sarah Hopwood" at Nov 26, 9 05:15:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 05:50:25 -0000 David-Sarah Hopwood wrote: > > The old verify_data should not just be appended to the handshake_messages > without any further encoding, though, because it might match the bytes > of some valid handshake message. In that case, there is the possibility > that a MITM might insert the old verify_data into the stream sent to > one peer, as though it were a handshake message. If that peer is using > the unmodified Finished computation (either because it is unpatched or > it is doing an initial handshake), then it may end up computing the same > Finished hash as the other peer that is using the modified computation. > > I haven't gone through the details of this attack thoroughly enough > to be sure it will work, but it is too near working for comfort. There are no handshake messages after finished. You forgot the signaling in the ServerHello and ClientHello that is also covered by the handshake message hash. the verify_data should be added directly following ServerHello. -Martin From ynir@checkpoint.com Wed Nov 25 22:24:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516143A68E0 for ; Wed, 25 Nov 2009 22:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 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 evI-CRjkfBmm for ; Wed, 25 Nov 2009 22:24:35 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1D9193A692F for ; Wed, 25 Nov 2009 22:24:35 -0800 (PST) X-CheckPoint: {4B0E1B5A-1-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3648B29C009; Thu, 26 Nov 2009 08:24:25 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1258429C002; Thu, 26 Nov 2009 08:24:25 +0200 (IST) X-CheckPoint: {4B0E1B56-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAQ6OOGo020233; Thu, 26 Nov 2009 08:24:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 26 Nov 2009 08:24:30 +0200 From: Yoav Nir To: "Michael D'Errico" Date: Thu, 26 Nov 2009 08:24:20 +0200 Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: AcpuYRuT78s3hy1hSwGzE617R1X/VA== Message-ID: <8A26F413-5C64-41BA-99FC-FBAB76B963D9@checkpoint.com> References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <4B0DBB97.5050500@pobox.com> <4B0DFB03.5020201@pobox.com> In-Reply-To: <4B0DFB03.5020201@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: TLS Working Group Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 06:24:36 -0000 What David-Sarah said, but you could XOR it with the master_secret as input= to the PRF, or even better, use it instead of the finished_label. This way, you don't have to worry about where to put it in the handshake me= ssage stream, just keep it from the previous session. On Nov 26, 2009, at 5:50 AM, Michael D'Errico wrote: >> Eric Rescorla wrote: >>=20 >>>> 3) Incorporate previous verify_data into Finished calc. >>>=20 >>> I'm not happy with this, actually. >=20 > Would this work: >=20 > Finished =3D verify_data XOR previous_verify_data >=20 >=20 > Not sure if anyone has suggested that already.... >=20 > Does it work if you renegotiate twice or more times? >=20 > Also how to handle if renegotiation changes TLS version (SSLv3 > verify_data is 36 bytes long). >=20 From djhopwood@googlemail.com Wed Nov 25 22:56:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F152D3A677E for ; Wed, 25 Nov 2009 22:56:11 -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 di2r0Y1Ck-dr for ; Wed, 25 Nov 2009 22:56:11 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 99D293A69E2 for ; Wed, 25 Nov 2009 22:56:10 -0800 (PST) Received: by ewy6 with SMTP id 6so472798ewy.29 for ; Wed, 25 Nov 2009 22:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=nfHBQ2f+PXMXqtvetl57DgBfVW3j3wsV+nZ82429xf4=; b=Uvagr5U2HQ+VR/anoJmkb7dgd/+bLCw+InMyx6OQqa61i+nLTFw7+tL3ZL1Y8nhJ7X mkEgnESSc93q5UC8SliCST3jONtVpmiFPgu6D8tmVYJ8RS4ciyOKZLrmT+XAPl58y8yq 56VhFuI/yRT2dVYpA+53brbe+xKbh4XA+6yhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=kD6HeZknU9vDiFoUWbcl2Z8mBGjYnFflPrmXUN5w04cjlmmg9eCze9VORXBVvFpoiS wKzcMB4GffodYsRJ5tExM/pXyhuf41ltwsyNMyoYqYznhAq2vf8VvllO8syAJ4r7devq EODanmQD3iOaovsv2G2Bk5SZBecFMxuQjuAGA= Received: by 10.213.23.201 with SMTP id s9mr2431274ebb.15.1259218560424; Wed, 25 Nov 2009 22:56:00 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm192851ewy.0.2009.11.25.22.55.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 22:55:59 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0E267F.1080102@jacaranda.org> Date: Thu, 26 Nov 2009 06:55:59 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911260550.nAQ5oID8027283@fs4113.wdf.sap.corp> In-Reply-To: <200911260550.nAQ5oID8027283@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2AA0730617BCB0D940917CD2" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 06:56:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2AA0730617BCB0D940917CD2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > David-Sarah Hopwood wrote: >> The old verify_data should not just be appended to the handshake_messa= ges >> without any further encoding, though, because it might match the bytes= >> of some valid handshake message. In that case, there is the possibilit= y >> that a MITM might insert the old verify_data into the stream sent to >> one peer, as though it were a handshake message. If that peer is using= >> the unmodified Finished computation (either because it is unpatched or= >> it is doing an initial handshake), then it may end up computing the sa= me >> Finished hash as the other peer that is using the modified computation= =2E >> >> I haven't gone through the details of this attack thoroughly enough >> to be sure it will work, but it is too near working for comfort. >=20 > There are no handshake messages after finished. That's not relevant. > You forgot the signaling in the ServerHello and ClientHello > that is also covered by the handshake message hash. It appears that is indeed not vulnerable, because of the requirement that allow_old_reneg= o MUST be set to false when the peer is found not to be updated. Previous summaries of the proposal on the list were not clear about this; they implied that updating the finished hash would automatically make renegotiations with an unupdated peer fail. Note, however, that (unless it is changed as I suggested) this contradicts one of the claimed advantages over RI. > the verify_data should be added directly following ServerHello. Yes, that's where the attacker would send it. (You may have been confused by my choice of the word "appended"; I meant "appended at the point where the it is known that the new Finished computation will be used".) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig2AA0730617BCB0D940917CD2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksOJogACgkQWUc8YzyzqAdu4QD9HeBdn6xNm3L5QMD6hfFG39KH MCHT+qtcPw8lZFo9W88A/2t65xorB4LIDdc77U1YGPHPBpzwfM8snPb1z6D/dtvn =sMwe -----END PGP SIGNATURE----- --------------enig2AA0730617BCB0D940917CD2-- From Pasi.Eronen@nokia.com Wed Nov 25 23:04:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390E83A6842 for ; Wed, 25 Nov 2009 23:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 4xcLE5UWJlEA for ; Wed, 25 Nov 2009 23:04:15 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1E38E3A69DF for ; Wed, 25 Nov 2009 23:04:15 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAQ747cV015557; Thu, 26 Nov 2009 01:04:09 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 09:04:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 09:04:02 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 26 Nov 2009 08:03:49 +0100 From: To: , Date: Thu, 26 Nov 2009 08:03:48 +0100 Thread-Topic: [TLS] Avoiding first use of RI in ClientHello Thread-Index: AcpuH3ZrIZ1RC3xLTWCsRfZA8p6WWgARvJgQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113E20C@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091125223502.4265B6C3285@kilo.networkresonance.com> In-Reply-To: <20091125223502.4265B6C3285@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2009 07:04:02.0535 (UTC) FILETIME=[A27DBF70:01CA6E66] X-Nokia-AV: Clean Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 07:04:16 -0000 I agree that minimal risk of breaking things that currently work is important for timely deployment of the fix. The proposed change seems to address many of the concerns raised so far, and significantly improves on the -00 draft. If it's quite unlikely to break things that currently work, and reasonably simple to implement (e.g., avoids the need for fall-back to extension-less handshake, which can't be necessarily implemented by the TLS library -- this is a big change to the -00 draft), I'd say we're reaching "good enough", and timely publication is more important than the exact bits. Unless the WG believes these goals are not actually met (that is, this still could break too many things, or is excessively complex to implement/deploy), I'd like to see an updated draft soon, and start IETF Last Call. Best regards, Pasi > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Eric Rescorla > Sent: 26 November, 2009 00:35 > To: tls@ietf.org > Subject: [TLS] Avoiding first use of RI in ClientHello >=20 > Folks, >=20 > I wanted to try to resolve what I see as the major technical concern > people have about draft-ietf-tls-renegotiation-00, namely that the > client cannot offer secure renegotiation and be sure that it won't > cause a connection failure with a downrev (extension noncompliant) > server. >=20 > There's been a lot of discussion of whether this is a serious problem, > but it's clear that minimal risk of breaking things that currently > work (which some folks think requires not using extensions in the > initial ClientHello) is important for the timely deployment of the > fix, and with the current draft, that may require fall-back to > extension-less handshake. >=20 > It's unclear how often such fall-back logic would actually be needed, > and I do find Nelson's "tough love" approach here sort of appealing, > but it does seem to be a problem that you don't necessarily know for > sure > whether you need it or not until you've actually shipped the product > with extensions, and possibly broken applications that currently work. > It's especially concerning that fall-back can't be implemented reliably > inside the TLS library, e.g., if you just get a filehandle, so changes > to the app logic are required. >=20 >=20 > The rest of this message describes a simple modification [*] to > draft-ietf-tls-negotiation which I think addresses this compatibility > issue without requiring fall-back. >=20 > The idea is to use a magic cipher suite to signal that the client can > securely renegotiate (as described in > draft-mrex-tls-secure-renegotiation). However, the server treats this > EXACTLY as if the client had offered an empty RI extension, and > responds with its own RI extension (or if it doesn't implement the > full extension framework, just adds a known byte string to the end of > the ServerHello). In other words: >=20 >=20 > Client Server > ------------------------------------------------------ > ClientHello + TLS_RENEGO_PROTECTION_REQUEST -> > <- ServerHello + Empty RI >=20 >=20 > At this point, the client now knows that the server supports secure > renegotiation and can simply send RI in any renegotiation handshake > (and if the client doesn't implement the full extensions framework, it > could just add a known byte string to the end of the ClientHello, > without requiring full extension support). Note that this is > reminiscent of the SSLv2->SSLv3 transition where clients would > initially offer backward compatibility handshakes but once they knew > the server was SSLv3-capable would offer the new ClientHello. >=20 >=20 > What about 5246 and unsolicited extensions? > As far as I can tell, the major argument against using extensions > for S->C signalling is the 5246 prohibition against the server > providing > unsolicited extensions. However, that was clearly intended to prevent > the server from sending extensions the client didn't expect and > that's not the case here. Moreover, we're updating 5246 so we can relax > the restriction for this extension (though I would think not in > general). >=20 >=20 > What about not putting the verify data in the extension? > I think that issue is separable from the question of how we signal > support, so would like to deal with it separately. (It seems this > won't make any difference for the bigger questions like can deploying > the fix break things that currently work, or whether you can implement > the fix purely inside the TLS library) >=20 >=20 > What about SSLv3? > Obviously, the ClientHello is compatible with SSLv3. (and the magic > cipher suite can be offered even in SSLv2 backward compatible > hello---ugh!). Although SSLv3 does not have the TLS extension > framework, we could also specify that the server (once it sees the > magic cipher suite indicating the client supports this draft) just > appends the relevant fixed-length byte string to the end of the > ServerHello. >=20 >=20 > What do people think about this approach? >=20 > -Ekr >=20 > [*] I didn't invent this approach, I'm just reproposing it to try to > focus > discussion. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Pasi.Eronen@nokia.com Wed Nov 25 23:18:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70F83A68DB for ; Wed, 25 Nov 2009 23:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 mXaX+bQE+TU2 for ; Wed, 25 Nov 2009 23:18:57 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8AB413A68A9 for ; Wed, 25 Nov 2009 23:18:56 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAQ7Ie3s005817; Thu, 26 Nov 2009 09:18:48 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 09:18:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 09:18:41 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 26 Nov 2009 08:18:40 +0100 From: To: , Date: Thu, 26 Nov 2009 08:18:38 +0100 Thread-Topic: [TLS] Avoiding first use of RI in ClientHello Thread-Index: AcpuJwPMd7cYlBH8Rp+Xbl7wy8C92gAP6oPQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113E22D@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091125223502.4265B6C3285@kilo.networkresonance.com> <4B0DBD9C.1090703@REDHAT.COM> In-Reply-To: <4B0DBD9C.1090703@REDHAT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2009 07:18:41.0200 (UTC) FILETIME=[AE376300:01CA6E68] X-Nokia-AV: Clean Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 07:18:58 -0000 Robert Relyea wrote: > This is not an RI specific issue. TLS already defines a number of > extensions. This fallback policy was implemented not because > extension noncompliant servers were particularly important, but > because implementations needed to have minimal objections for moving > forward and actually using extensions. Today TLS clients regularly > use extensions, so adding one more to allow renegotiation should not > be an issue. It probably isn't for clients that *already* use extensions. The major PC/Mac/Linux web browsers do, but those are not the only TLS clients out there. I can see that it could be a big issue for clients that today do not send extensions. Not because extensions themselves are difficult to implement, but as Eric pointed out, the fallback logic could be very difficult to implement (and may require changing applications), and most importantly, if you don't send extensions currently, you don't=20 really know whether you need the fallback logic before you've broken=20 things that work today... Best regards, Pasi (not wearing any hats) From mrex@sap.com Wed Nov 25 23:35:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429D93A69F2 for ; Wed, 25 Nov 2009 23:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 xIeqVxmMNeAD for ; Wed, 25 Nov 2009 23:35:45 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 356743A681A for ; Wed, 25 Nov 2009 23:35:45 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQ7ZciJ025256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 08:35:38 +0100 (MET) From: Martin Rex Message-Id: <200911260735.nAQ7ZbYP003893@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 26 Nov 2009 08:35:37 +0100 (MET) In-Reply-To: <4B0E0EF4.7000102@jacaranda.org> from "David-Sarah Hopwood" at Nov 26, 9 05:15:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 07:35:46 -0000 David-Sarah Hopwood wrote: > > The old verify_data should not just be appended to the handshake_messages > without any further encoding, though, because it might match the bytes > of some valid handshake message. In that case, there is the possibility > that a MITM might insert the old verify_data into the stream sent to > one peer, as though it were a handshake message. If that peer is using > the unmodified Finished computation (either because it is unpatched or > it is doing an initial handshake), then it may end up computing the same > Finished hash as the other peer that is using the modified computation. > > I haven't gone through the details of this attack thoroughly enough > to be sure it will work, but it is too near working for comfort. OK. you got a point! It's true that there is a theoretical attack. So Mikes idea to always add a length to the hash (and therefore also change the initial handshake between updated peers) was not so bad after all. > > 2. Add the old verify_data to handshake_messages preceded by the encoding > of a fatal alert. Then, attacks of the kind described above can't work > because the unpatched peer would first process the alert and abort the > handshake. Alerts are no handshake messages, so that doesn't work. different possibilities: - add a bodyless-finished message to the beginning of the handshake message hash of a secure renegotiation before the ClientHello a position where the attacker can not insert handshake messages - add something different to both handshake message hashes before adding the verify_data to the renegotiation handshake message hash - frame the Client.Finished.verify_data plus Server.Finished.verify_data as a Finished message - signal initial and renegotiation handshakes differently in the handshake -Martin From aerowolf@gmail.com Thu Nov 26 00:24:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2EF53A681C for ; Thu, 26 Nov 2009 00:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 BaUnPIXXXgHg for ; Thu, 26 Nov 2009 00:24:33 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id EE9D83A63EC for ; Thu, 26 Nov 2009 00:24:32 -0800 (PST) Received: by pzk6 with SMTP id 6so382076pzk.29 for ; Thu, 26 Nov 2009 00:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pAoCdWEMHyIwnLlEiuVvBmzvrHANHQtrDggVZUxAyzQ=; b=DxzghdMG1ReRQz8jW0cvjiysN190ObEePQyuR8/sdhhJJluiiV2QvfpYilBpP0PBm6 Ymo89eoud3VRpUl22XUmnfPEM30aI+p3D5Kcvj3OzpxvXYtLH1q9gogjjpOfS//wzDxx sKx913Mal4dAxEVcAtpMvWFDkvuGdR16/Zj3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=acOSh4nkybVDb5r0joVdcmk4EWmtVTR1tXQy5vtUmt0fD88lj0XwUB9BvDvoCYxmAt DDba2vIVEEPYBcUtyP74LLZNdC6qIBROIMBk8ue1F/CRVTHcMpu+aiLT5/EuR4ZnZP9E b+zZGI7iVexqxwoPFGfODLNplaTgIS2lVV05g= MIME-Version: 1.0 Received: by 10.142.150.41 with SMTP id x41mr975267wfd.243.1259223865371; Thu, 26 Nov 2009 00:24:25 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Nov 2009 00:24:25 -0800 Message-ID: <6b9359640911260024s2d2a7a12yf72e6ba3028a714e@mail.gmail.com> From: Kyle Hamilton To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] simplistic renego protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:24:33 -0000 The most simple fix for a 1023-bit key is to force the high bit to always be 1. (This was implemented in PGP 5 for RSA keys.) Who was the EV issuer? -Kyle H On Wed, Nov 25, 2009 at 5:08 PM, Peter Gutmann wrote: > "Yngve Nysaeter Pettersen" writes: > >>The reason I was investigating the site was that the EV indication was fl= ip- >>flopping on this site, which turned out to be because one certificate had= a >>1024 bit key (which qualifies for EV), the other was using a 1023 bit key >>(which does not qualify for EV). > > So the CA issued a certificate that it should never have issued? =C2=A0An= d then the > client did more checking than the CA did? =C2=A0Do other implementations = perform > this level of checking of EV conditions as well, or do they just assume t= hat > if the EV flag is set then everything must be OK because the CA says it i= s? > I'd be interested in feedback from on this one (private is OK if you don'= t feel > like making it public). > > Kinda scary if it's left to the RP to do the CA's work... > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From stefan@aaa-sec.com Thu Nov 26 00:28:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AF83A6A1C for ; Thu, 26 Nov 2009 00:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BZ5uBCsE6TU for ; Thu, 26 Nov 2009 00:28:46 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 4C0163A688D for ; Thu, 26 Nov 2009 00:28:46 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 505332912E7 for ; Thu, 26 Nov 2009 09:28:42 +0100 (CET) Received: (qmail 91592 invoked from network); 26 Nov 2009 08:28:39 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Nov 2009 08:28:39 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 26 Nov 2009 09:28:36 +0100 From: Stefan Santesson To: Eric Rescorla , Message-ID: Thread-Topic: Verify data in the RI extension? Thread-Index: AcpucnKDBfZJfFA4bkCu+kOI5DD7Ag== In-Reply-To: <20091125223502.4265B6C3285@kilo.networkresonance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:28:47 -0000 Eric and all, On 09-11-25 11:35 PM, "Eric Rescorla" wrote: > What about not putting the verify data in the extension? > I think that issue is separable from the question of how we signal > support, so would like to deal with it separately. I would like to elaborate my support for an RI with absent verify data. The major argument I have seen for including verify data in the RI extension is that it would allow us to preserve the current Finished calculation. This will allow us to use more of the current implementation code and provide a more clean design. I think these to a major extent are valid arguments, but I find the opposing arguments even more convincing. These are: 1) Empty RI It's good security design If you want to make sure two parties agree on a value that they have derived from a previous state, in order to bind to the previous state, then why would you exchange that value before doing the check? On the contrary, I find it to be good security design not to exchange that value as it: 1) Reduce information leakage to an attacker 2) Increase the security assumptions that can be made based on a proof of matching values (good Finished messages). Even if there are no attack today to exploit the information leakage and exchanging the values allows secure design, I still find it valuable to apply the best possible security design to reduce the chance of future problems. 2) Better migration path towards future If we would design TLS 1.3, then would we send this data in the handshake, or would we not? I suspect we would not, due to argument 1) Exchanging this value serves no purpose other than saving a few lines of code changes from TLS 1.2. Consequently, if we design an updated Finished calculation now, we can keep that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS 1.2. 3) Less likely to cause implementation problems This is just my guessing based on what I have heard. But if the client verify data is provided in RI, then it is not enough to recognize the extension. It is now also necessary to parse it, extract the data and to use it in a critical security check. I can't really judge how likely this is to cause more implementation problems or even implementations that appears to do the security check against previous handshakes, but actually just feeds it into the finished calculation blindly. But it feels like good design to eliminate/reduce this type of problems if possible. Especially if it is better security design at reasonable cost. /Stefan From aerowolf@gmail.com Thu Nov 26 00:34:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A51A3A6826 for ; Thu, 26 Nov 2009 00:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 1QL+wSphEF1J for ; Thu, 26 Nov 2009 00:34:00 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id A9D9B3A659B for ; Thu, 26 Nov 2009 00:34:00 -0800 (PST) Received: by pxi16 with SMTP id 16so388009pxi.29 for ; Thu, 26 Nov 2009 00:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EtM5hwpyJY5u/EJhA6MCNxoHDi55WN+XBbnYlSbmafg=; b=BxoEBdSenhEhsAqDJVRAgaw9x+I8x86VIW6lAODW4cgn0puW2aLF2mKIjtJZAs5Jbt nzbK5TweQY23fDXhZxbvl0GXhvefR+LsRgZqLGTyERLjnsDoBEu4y0cs01pjN97s8/ba H3y/wfcPLuJlqA6LLOfT/obmIOOLb1FIcUDbA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=brpS89w5tKFnhcN336dZDidq+Fh16uVdnwP998NDomZJydSWRlRPWTmL4uUhVyorCU a0o/8N4Ou+Y6kh0/ANJRX0weQmXSLmSs4Pk7golUYm6kAYuzKMw/5Dz3NZTbUx9wtqr4 O9XRYV0QsYdFwwvwu8xUymVfeAkgu0B2TOyMw= MIME-Version: 1.0 Received: by 10.142.75.12 with SMTP id x12mr882399wfa.157.1259224433137; Thu, 26 Nov 2009 00:33:53 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Nov 2009 00:33:53 -0800 Message-ID: <6b9359640911260033q4eee63f3sb43aa76c657453b7@mail.gmail.com> From: Kyle Hamilton To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:34:01 -0000 We've already heard that Microsoft IIS sends an extension in the case of working with a particular cipher, even in the event that the client didn't request the extension. (It contains the information necessary to work with the cipher suite.) If this protocol revision is documented as having the client send a special cipher suite tag, AND then the server will send some extra data after the ExtendedServerHello no matter what version of the protocol is in use, then anyone who implements the cipher suite tag should have also implemented the check for server support. Now, I'm going to turn this around a bit: what if a client sends that it knows how to do the new renegotiation, and then doesn't? How long would it take for the server to catch on? Is there an attack vector here? (Would the server want to immediately initiate a renegotiation to verify?) -Kyle H On Wed, Nov 25, 2009 at 1:39 AM, Yoav Nir wrote: > > On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote: > >> So how would this work as a middle way between the proposals: >> >> C->S Signaling: >> 1) Client MUST include either the magic CipherSuite or RI extension or both >> 2a) TLS compatible server MUST support magic CipherSuite and RI. >> 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI > > How about: > 2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI > 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support RI > >> S->C Signaling: >> 1) Servers MUST include RI > > Since this violates the TLS specs, I think servers MUST include RI only if the client included RI. Otherwise, they MUST use the tbd "other signal" > >> Finished calculation: >> 1a) The RI of the serverHello holds necessary data from previous handshake; >> or >> 1b) Finished calculation is modified to include virtual handshake messages >> >> >> This would allow the current implementation of RI (more or less) but also >> allow safe fallback when connecting to servers that can't parse extensions. >> >> All servers must include the bits of an RI extension in the server Hello, >> but that should be a lot easier than to implement full extension handling >> for receiving RI from the client. >> >> This would at least save us the ugliest hacks when it comes to S->C >> signaling. >> >> /Stefan > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Pasi.Eronen@nokia.com Thu Nov 26 00:35:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDB73A69FB for ; Thu, 26 Nov 2009 00:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 OjUeq+bFBxb4 for ; Thu, 26 Nov 2009 00:35:29 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A97CA3A6A22 for ; Thu, 26 Nov 2009 00:35:28 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAQ8ZHVL010599; Thu, 26 Nov 2009 10:35:19 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 10:35:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 10:35:11 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 26 Nov 2009 09:35:10 +0100 From: To: , Date: Thu, 26 Nov 2009 09:35:09 +0100 Thread-Topic: [TLS] some questions for your draftx Thread-Index: AcpuCQrKMB/M0HQyT0aB+ENNAaN87gAaWFPg Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113E31C@NOK-EUMSG-01.mgdnok.nokia.com> References: <4B0D7A36.5070808@extendedsubset.com> <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> <6b9359640911251153o338f5175m78a20d62e449c7cc@mail.gmail.com> In-Reply-To: <6b9359640911251153o338f5175m78a20d62e449c7cc@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2009 08:35:11.0442 (UTC) FILETIME=[5E36BB20:01CA6E73] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draftx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:35:30 -0000 VGhlIGN1cnJlbnQgdGV4dCAoaW4gdGhlIC0wMCBkcmFmdCkgYmFzaWNhbGx5IHNheXMgImlkZW50 aXR5IGNoYW5nZXMNCmFyZSBPSywgYnV0IG9ubHkgaWYgdGhlIGFwcGxpY2F0aW9uIHVuZGVyc3Rh bmRzIHRoZW0iLg0KDQooQW5kIGJ5IGRlZmF1bHQsIHRoZSBUTFMgbGlicmFyeSBtdXN0IGFzc3Vt ZSB0aGUgYXBwbGljYXRpb24gaGFzbid0DQpwcm9iYWJseSB0aG91Z2h0IHRoYXQgc29tZXRoaW5n IGxpa2UgbXlDb25uLmdldFBlZXJDZXJ0aWZpY2F0ZXMoKSANCmNvdWxkIHJldHVybiBhIGRpZmZl cmVudCB2YWx1ZSBlYWNoIHRpbWUgaXQncyBjYWxsZWQuIEFuZCB0aGUgDQphcHBsaWNhdGlvbiBt aWdodCBoYXZlIGRpZmZpY3VsdGllcyBpbiBmaWd1cmluZyBvdXQgd2hpY2ggY2VydA0Kd2FzIHVz ZWQgZm9yIHdoaWNoIGFwcGxpY2F0aW9uLWxldmVsIG1lc3NhZ2UvdHJhbnNhY3Rpb24sIHNpbmNl DQp0aGUgVExTIGxpYnJhcnkgb2Z0ZW4gZ2l2ZXMganVzdCBhIGJ5dGUgc3RyZWFtLCBub3QgYSBi eXRlIHN0cmVhbQ0Kd2hlcmUgZWFjaCBieXRlIGlzIGFubm90YXRlZCB3aXRoIHRoZSBjZXJ0aWZp Y2F0ZS4pDQoNClNvIGFsbCB0aGUgdXNlIGNhc2VzIGZvciBpZGVudGl0eSBjaGFuZ2VzIHlvdSBt ZW50aW9uIHdvdWxkIHN0aWxsDQpiZSBhbGxvd2VkLg0KDQpCZXN0IHJlZ2FyZHMsDQpQYXNpDQoo bm90IHdlYXJpbmcgYW55IGhhdHMpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+IGV4dCBLeWxlIEhhbWlsdG9uDQo+IFNlbnQ6IDI1IE5vdmVtYmVyLCAy MDA5IDIxOjU0DQo+IFRvOiBtcmV4QHNhcC5jb20NCj4gQ2M6IHRsc0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW1RMU10gc29tZSBxdWVzdGlvbnMgZm9yIHlvdXIgZHJhZnR4DQo+IA0KPiBEbyAq bm90KiBwdXQgYW55IGFyYml0cmFyeSBwb2xpY3kgZGVjaXNpb25zIGludG8gYW4gSUVURiBzdGFu ZGFyZC4NCj4gU3VjaCBhcyAibXVzdCBub3QgY2hhbmdlIElkZW50aXR5Ii4NCj4gDQo+IEkgY2Fu IHNlZSAqc2V2ZXJhbCogc2l0dWF0aW9ucyB3aGVyZSBhbiBpZGVudGl0eSBjb3VsZCBiZSB1c2Vm dWxseQ0KPiBjaGFuZ2VkIGluc2lkZSBhIGNvbm5lY3Rpb24gLS0gZm9yIGV4YW1wbGUsIGEgbWFu YWdlciBwdXR0aW5nIGluIGhlcg0KPiBzbWFydCBjYXJkIChvbiB0aGUgc2FtZSBtYWNoaW5lIGFz IHRoZSB3b3JrZXIpIGFuZCBrZXlpbmcgaW4gaGVyIHBpbiwNCj4gdG8gYmUgcHJvbXB0ZWQgYnkg dGhlIHNlcnZlciB0byBhdXRob3JpemUgYSBnaXZlbiB0cmFuc2FjdGlvbiAtLSBhbmQNCj4gdGhl biBwdWxsaW5nIHRoZSBzbWFydCBjYXJkIG91dCBhZ2FpbiwgdGh1cyByZW1vdmluZyB0aGUgY2Fw YWJpbGl0eSB0bw0KPiB1c2UgdGhhdCBrZXkuICAoVGhpcyBpcyB0aGUga2luZCBvZiB0aGluZyB0 aGF0IGlzIGRvbmUgYXQsIGZvcg0KPiBleGFtcGxlLCBGcnkncyBFbGVjdHJvbmljcy4uLiBleGNl cHQgdGhhdCB0aGV5IGp1c3QgdXNlIHVzZXJuYW1lcyBhbmQNCj4gcGFzc3dvcmRzIHRvIGF1dGhl bnRpY2F0ZSBhbmQgYXV0aG9yaXplLikNCj4gDQo+IEFub3RoZXIgaXMgdGhlIGNhc2Ugd2hlcmUg YSBnaXZlbiBpZGVudGl0eSBpcyB1bmFjY2VwdGFibGUgZm9yIHNvbWUNCj4gb3BlcmF0aW9uIC0t IGZvciBleGFtcGxlLCBJIGVuZCB1cCB1c2luZyBteSBreWFuaGFBVGt5YW5oYURPVG5ldA0KPiBj ZXJ0aWZpY2F0ZSB0byB0cnkgdG8gZG8gc29tZXRoaW5nIHRoYXQgb25seSBhZXJvd29sZkBnbWFp bC5jb20gaXMNCj4gYWxsb3dlZCB0byBkby4gIEknZCBwcmVmZXIgdG8ga2VlcCB0aGUgc2FtZSBU TFMgY29ubmVjdGlvbiwganVzdA0KPiBjaGFuZ2UgdGhlIGlkZW50aXR5IHRoYXQgaXQncyBib3Vu ZCB0by4NCj4gDQo+IChXaGF0IGFib3V0IHRoZSBzaXR1YXRpb24gd2hlcmUgeW91ciBjZXJ0IGhh cyBiZWVuIHJldm9rZWQgYW5kIE9DU1AgaXMNCj4gc2F5aW5nIHRoYXQgaXQgaXMsIGFuZCB5b3Un cmUgdHJ5aW5nIHRvIHB1dCBhIHJlcGxhY2VtZW50IGludG8gcGxhY2U/DQo+IE9yLCBpZiB0aGUg cm9vdCB5b3UndmUgYmVlbiB1c2luZyBoYXMgYmVlbiBkcm9wcGVkIGZyb20gdGhlIFRydXN0IExp c3QNCj4gb2Ygd2hhdGV2ZXIgYnJvd3NlciB5b3VyIGNsaWVudHMgYXJlIHVzaW5nIC0tIHlvdSdy ZSBzdWRkZW5seQ0KPiB1bnRydXN0ZWQuICBTbyB5b3UgbmVlZCB0byBnZXQgYSBjb21wbGV0ZWx5 IGRpZmZlcmVudCBzaWduZXIgLS0gYW5kDQo+IHRoYXQgd2lsbCBjb21wbGV0ZWx5IGZhaWwgdGhl IG1lbWNtcCB0ZXN0LiAgSXQgbWlnaHQgZXZlbiBmYWlsIHN0cmNtcA0KPiBvbiB0aGUgY29tcG9u ZW50cyBvZiB0aGUgU3ViamVjdC4gIFJlZ2FyZGxlc3MsIHRoaXMgaXMgb3V0c2lkZSB0aGUNCj4g c2NvcGUgb2YgVExTOyBpdCBpcyB0aGUgYXBwbGljYXRpb24gZGVzaWduZXIgYW5kIHRoZSBhcHBs aWNhdGlvbg0KPiBjb25zdW1lciB3aG8gZGV0ZXJtaW5lIHRoZSBzZWN1cml0eSBwb2xpY3kgdGhh dCB0aGV5J3JlIGdvaW5nIHRvIHVzZSwNCj4gbm90IGFueSBvbmUgb2YgdXMuKQ0KPiANCj4gLUt5 bGUgSA0KPiANCj4gT24gV2VkLCBOb3YgMjUsIDIwMDkgYXQgMTA6NTIgQU0sIE1hcnRpbiBSZXgg PG1yZXhAc2FwLmNvbT4gd3JvdGU6DQo+ID4gTWFyc2ggUmF5IHdyb3RlOg0KPiA+Pg0KPiA+PiBN YXJ0aW4gUmV4IHdyb3RlOg0KPiA+PiA+IE1hcnNoIFJheSB3cm90ZToNCj4gPj4gPj4gTWFydGlu IFJleCB3cm90ZToNCj4gPj4gPj4+IEknbSBhY3R1YWxseSB2ZXJ5IGZhdm91cmFibGUgb2YgYSBy ZXN0cmljdGlvbiB0aGF0IGFscmVhZHkNCj4gZXN0YWJsaXNoZWQNCj4gPj4gPj4+IGlkZW50aXRp ZXMgKG5vdCB0aGUgbGFjayB0aGVyZW9mISkgbXVzdCBub3QgY2hhbmdlIGR1cmluZw0KPiByZW5l Z290aWF0b24sDQo+ID4+ID4+PiBhbmQgY29udGVtcGxhdGluZyB0byBhZGQgdGhpcyBpbnRvIG15 IHByb3Bvc2FsIGFzIHdlbGwuDQo+ID4+ID4+IEkgYmVsaWV2ZSB0aGUgY3VycmVudCBUTFMgc3Bl Y3MgZG8gbm90IGhhdmUgYSBzdWZmaWNpZW50bHkNCj4gcmlnb3JvdXMNCj4gPj4gPj4gZGVmaW5p dGlvbiBvZiAiaWRlbnRpdHkiIGluIG9yZGVyIHRvIGJlIG1hbmRhdGluZyByZXN0cmljdGlvbnMN Cj4gbGlrZQ0KPiA+PiA+PiB0aGlzLiBtZW1jbXAoKSBvZiBjZXJ0cyBkb2Vzbid0IGN1dCBpdC4g QXQgYmVzdCwgdGhleSB3aWxsIGJlDQo+IGlnbm9yZWQuDQo+ID4+ID4+IEF0IHdvcnN0LCB0aGV5 IHdpbGwgZW50aWNlIGRldmVsb3BlcnMgdG8gbWFrZSB1bnNhZmUgYXNzdW1wdGlvbnMuDQo+ID4+ ID4NCj4gPj4gPiBtZW1jbXAoKSBvZiB0aGUgY2VydHMgaXMgdGhlIG9ubHkgd2F5IFRMUyBjYW4g aW1wbGVtZW50IHRoaXMuDQo+ID4+ID4gVGhpcyBpcyB0aGUgb25seSBjb25jZXB0IG9mIGlkZW50 aWNhbCBrbm93biB0byBUTFMuDQo+ID4+DQo+ID4+IEl0J3MgYSBwcmV0dHkgd2VhayBjb25jZXB0 IG9mICJpZGVudGl0eSIsIHRvby4NCj4gPg0KPiA+IEl0IGlzIHRoZSBzdHJvbmdlc3QgcG9zc2li bGUgY29uY2VwdCBvZiAiZXF1aXZhbGVudCBpZGVudGl0eSIgaW4NCj4gZXhpc3RhbmNlLg0KPiA+ DQo+ID4gSXQgaXMgYWxzbyB0aGUgb25seSBvbmUgZm9yIHdoaWNoIEkgY29uc2lkZXIgYSBmdWxs IHJlLWF1dGhlbnRpY2F0aW9uDQo+ID4gZGlzcGVuc2FibGUuDQo+ID4NCj4gPiBXaGljaCBpcyB3 aGF0IEknbSB0cnlpbmcgdG8gYWNoaWV2ZS4gwqBJIHdvdWxkIG5vdCBrbm93IGhvdyB0byBmb3Jj ZQ0KPiA+IGEgcmUtYXV0aGVudGljYXRpb24gb250byBhbiBleGlzdGluZyBjbGllbnQgYXBwLg0K PiA+DQo+ID4NCj4gPj4NCj4gPj4gVGhlIHNwZWMgaXMgc2F5aW5nIG5vdCB0byBkbyB3aGF0IHlv dSBhZHZvY2F0ZSBiZWNhdXNlIGl0J3Mgb3V0c2lkZQ0KPiB0aGUNCj4gPj4gc2NvcGUgb2YgVExT Lg0KPiA+DQo+ID4gVGhlIHNwZWMgc2F5cyB0aGF0IFRMUyBkb2VzIG5vdCBpbmNsdWRlIGF1dGhl bnRpY2F0aW9uDQo+ID4gKGl0IG9mdGVuIHBlcmZvcm1zIGNlcnRpZmljYXRlIHBhdGggdmFsaWRh dGlvbiwgdGhvdWdoKS4NCj4gPg0KPiA+Pg0KPiA+PiA+IFllcywgSSdtIGF3YXJlIHRoYXQgYSBt ZW1jbXAoKSByZXN0cmljdGlvbiBpcyBnb2luZyB0byBjYXVzZQ0KPiA+PiA+IGEgZGlzcnVwdGlv biBmb3IgU2VydmVycyB0aGF0IGJvdGgsIGFjdGl2ZWx5IHVzZSByZW5lZ290aWF0aW9uIGFuZA0K PiA+PiA+IGFsbG93IHNlcnZlciBjZXJ0aWZpY2F0ZXMgdG8gYmUgdXBkYXRlZCBpbi1mbGlnaHQu IChBIGxvdCBvZg0KPiBzZXJ2ZXJzDQo+ID4+ID4gcmVxdWlyZSBhIHJlc3RhcnQgZm9yIHJlcGxh Y2luZy91cGRhdGluZyB0aGUgc2VydmVyIGNlcnRpZmljYXRlLA0KPiB0aG91Z2gpLg0KPiA+Pg0K PiA+PiBUaGVuIHBsZWFzZSBwbGVhc2UgZG9uJ3QgYnVuZGxlIGl0IGluIHdpdGggd2hhdCBpcyBz dXBwb3NlZCB0byBiZSBhbg0KPiA+PiB1cmdlbnQgYnVnZml4Lg0KPiA+DQo+ID4gSSB0aGluayB3 ZSBkbyBoYXZlIGFub3RoZXIgc2VjdXJpdHkgcHJvYmxlbSBoZXJlIHRoYXQNCj4gPiB3ZSBzaG91 bGQgZml4LiDCoFRoZXJlIG1heSBiZSBhIG51bWJlciBvZiBhcHBzIHRoYXQgc2ltcGx5IGRvIG5v dA0KPiA+IGV4cGVjdCB0aGF0IHRoZXkgaGF2ZSB0byByZWF1dGhlbnRpY2F0ZSBpZiByZW5lZ290 YXRpb24gYWxsb3dzDQo+ID4gdGhlIGlkZW50aXR5IHRvIGNoYW5nZS4NCj4gPg0KPiA+IENvdWxk IHlvdSBlbGFib3JhdGUgb24gdXNhZ2Ugc2NlbmFyaW9zIHdoaWNoIG1pZ2h0IGJlIGFkdmVyc2x5 DQo+IGFmZmVjdGVkDQo+ID4gYnkgc3VjaCBhIHJlcXVpcmVtZW50L2NvbnN0cmFpbnQ/DQo+ID4N Cj4gPg0KPiA+IC1NYXJ0aW4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gVExTIG1haWxpbmcgbGlzdA0KPiA+IFRMU0BpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+ID4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVExTIG1h aWxpbmcgbGlzdA0KPiBUTFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHMNCg== From Pasi.Eronen@nokia.com Thu Nov 26 00:38:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D64C3A6A45 for ; Thu, 26 Nov 2009 00:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 yjBcyXHq8O7s for ; Thu, 26 Nov 2009 00:38:49 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 953413A6A3A for ; Thu, 26 Nov 2009 00:38:49 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAQ8cXCB004414; Thu, 26 Nov 2009 02:38:43 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 10:38:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 10:38:14 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 26 Nov 2009 09:38:13 +0100 From: To: , Date: Thu, 26 Nov 2009 09:38:13 +0100 Thread-Topic: [TLS] some questions for your draft Thread-Index: AcpuD3tLMSMAvmDuQ/GtW9m4H3SB6gAY/m3g Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113E326@NOK-EUMSG-01.mgdnok.nokia.com> References: <200911251724.nAPHOMf2007151@fs4113.wdf.sap.corp> <4B0D6A7B.1040803@extendedsubset.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2009 08:38:14.0952 (UTC) FILETIME=[CB982280:01CA6E73] X-Nokia-AV: Clean Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:38:50 -0000 Bruno Harbulot: > One could imagine a situation where a client would initially present > a client certificate that contains attributes (like an attribute > certificate), but that doesn't embed the attributes the server wants > for this particular request. The server could then initiate a re- > negotiation to ask the client to present another certificate, with > other attributes. This can be particularly useful for role-based > (or virtual organisation) authorisation, for example. The concept > of identity then becomes rather loose; in some contexts, anonymity > might even be required. >=20 > I don't think that TLS should address this; rather, it should be up > to the components that verify the certificates. The current text in -00 allows the use case you describe above. If the components that verify/use the certificates support identity changes, that's just fine. The text just requires that if the component has been written without considering possible identity changes, the TLS library should not "surprise" it... Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Thu Nov 26 00:41:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763DC3A6A6E for ; Thu, 26 Nov 2009 00:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 wAKYoUMpGk0C for ; Thu, 26 Nov 2009 00:41:06 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 340453A6A3A for ; Thu, 26 Nov 2009 00:41:05 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAQ8eJ0O014705; Thu, 26 Nov 2009 10:40:51 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 10:40:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 10:40:14 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 26 Nov 2009 09:40:11 +0100 From: To: Date: Thu, 26 Nov 2009 09:40:10 +0100 Thread-Topic: [TLS] some questions for your draft Thread-Index: AcpuTFRr66244Y51TOGvuFKmms972gAJ4W1g Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113E32E@NOK-EUMSG-01.mgdnok.nokia.com> References: <200911251724.nAPHOMf2007151@fs4113.wdf.sap.corp> <4B0D6A7B.1040803@extendedsubset.com> <09fb01ca6e4c$45f93410$5b9a1b0a@china.huawei.com> In-Reply-To: <09fb01ca6e4c$45f93410$5b9a1b0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2009 08:40:14.0906 (UTC) FILETIME=[1317A9A0:01CA6E74] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:41:07 -0000 yangqinqin wrote: > For identity comparison during renegotiation,TLS may only do > memcmp() , and more complex identity comparison can be left to > Specific application to do. There shloud have a alarm message to > applications and leave applications to choose whether to continue > re-negotiation. This is essentially what the text in the -00 draft says: if the application chooses to continue, it can do so. Best regards, Pasi (not wearing any hats) From stefan@aaa-sec.com Thu Nov 26 00:46:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D313A6A6E for ; Thu, 26 Nov 2009 00:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l1ulcuoAP+y for ; Thu, 26 Nov 2009 00:46:28 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 7EB2E3A6B09 for ; Thu, 26 Nov 2009 00:46:27 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C5F9A29348E for ; Thu, 26 Nov 2009 09:46:24 +0100 (CET) Received: (qmail 2734 invoked from network); 26 Nov 2009 08:46:22 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Nov 2009 08:46:22 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 26 Nov 2009 09:46:20 +0100 From: Stefan Santesson To: Eric Rescorla , Message-ID: Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpucnKDBfZJfFA4bkCu+kOI5DD7AgAAnow/ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:46:29 -0000 Just elaborating that I think, based on these arguments, that the verify data should neither be added to the PRF or any other current handshake message. I.e. I support Michaels proposal in this regard. /Stefan On 09-11-26 9:28 AM, "Stefan Santesson" wrote: > Eric and all, > > On 09-11-25 11:35 PM, "Eric Rescorla" wrote: > >> What about not putting the verify data in the extension? >> I think that issue is separable from the question of how we signal >> support, so would like to deal with it separately. > > I would like to elaborate my support for an RI with absent verify data. > > The major argument I have seen for including verify data in the RI extension > is that it would allow us to preserve the current Finished calculation. This > will allow us to use more of the current implementation code and provide a > more clean design. > > I think these to a major extent are valid arguments, but I find the opposing > arguments even more convincing. These are: > > > 1) Empty RI It's good security design > > If you want to make sure two parties agree on a value that they have derived > from a previous state, in order to bind to the previous state, then why > would you exchange that value before doing the check? > > On the contrary, I find it to be good security design not to exchange that > value as it: > > 1) Reduce information leakage to an attacker > 2) Increase the security assumptions that can be made based on a proof of > matching values (good Finished messages). > > Even if there are no attack today to exploit the information leakage and > exchanging the values allows secure design, I still find it valuable to > apply the best possible security design to reduce the chance of future > problems. > > > 2) Better migration path towards future > > If we would design TLS 1.3, then would we send this data in the handshake, > or would we not? > > I suspect we would not, due to argument 1) > Exchanging this value serves no purpose other than saving a few lines of > code changes from TLS 1.2. > > Consequently, if we design an updated Finished calculation now, we can keep > that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS > 1.2. > > > 3) Less likely to cause implementation problems > > This is just my guessing based on what I have heard. > But if the client verify data is provided in RI, then it is not enough to > recognize the extension. It is now also necessary to parse it, extract the > data and to use it in a critical security check. > > I can't really judge how likely this is to cause more implementation > problems or even implementations that appears to do the security check > against previous handshakes, but actually just feeds it into the finished > calculation blindly. > > But it feels like good design to eliminate/reduce this type of problems if > possible. Especially if it is better security design at reasonable cost. > > /Stefan > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ynir@checkpoint.com Thu Nov 26 00:51:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A343A6A1D for ; Thu, 26 Nov 2009 00:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 rZ4VS7IILr1a for ; Thu, 26 Nov 2009 00:51:23 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A5F873A63EC for ; Thu, 26 Nov 2009 00:51:22 -0800 (PST) X-CheckPoint: {4B0E3DC1-1-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 543EF29C008; Thu, 26 Nov 2009 10:51:16 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2124629C002; Thu, 26 Nov 2009 10:51:16 +0200 (IST) X-CheckPoint: {4B0E3DC0-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAQ8pFGo024759; Thu, 26 Nov 2009 10:51:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 26 Nov 2009 10:51:21 +0200 From: Yoav Nir To: Stefan Santesson Date: Thu, 26 Nov 2009 10:51:11 +0200 Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQ== Message-ID: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:51:24 -0000 On Nov 26, 2009, at 10:28 AM, Stefan Santesson wrote: > Eric and all, >=20 > On 09-11-25 11:35 PM, "Eric Rescorla" wrote: >=20 >> What about not putting the verify data in the extension? >> I think that issue is separable from the question of how we signal >> support, so would like to deal with it separately. >=20 > I would like to elaborate my support for an RI with absent verify data. >=20 > The major argument I have seen for including verify data in the RI extens= ion > is that it would allow us to preserve the current Finished calculation. T= his > will allow us to use more of the current implementation code and provide = a > more clean design. >=20 > I think these to a major extent are valid arguments, but I find the oppos= ing > arguments even more convincing. These are: >=20 >=20 > 1) Empty RI It's good security design >=20 > If you want to make sure two parties agree on a value that they have deri= ved > from a previous state, in order to bind to the previous state, then why > would you exchange that value before doing the check? >=20 > On the contrary, I find it to be good security design not to exchange tha= t > value as it: >=20 > 1) Reduce information leakage to an attacker > 2) Increase the security assumptions that can be made based on a proof of > matching values (good Finished messages). >=20 > Even if there are no attack today to exploit the information leakage and > exchanging the values allows secure design, I still find it valuable to > apply the best possible security design to reduce the chance of future > problems.=20 Agree > 2) Better migration path towards future >=20 > If we would design TLS 1.3, then would we send this data in the handshake= , > or would we not? >=20 > I suspect we would not, due to argument 1) > Exchanging this value serves no purpose other than saving a few lines of > code changes from TLS 1.2. >=20 > Consequently, if we design an updated Finished calculation now, we can ke= ep > that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS > 1.2. Agree > 3) Less likely to cause implementation problems >=20 > This is just my guessing based on what I have heard. > But if the client verify data is provided in RI, then it is not enough to > recognize the extension. It is now also necessary to parse it, extract th= e > data and to use it in a critical security check. >=20 > I can't really judge how likely this is to cause more implementation > problems or even implementations that appears to do the security check > against previous handshakes, but actually just feeds it into the finished > calculation blindly. >=20 > But it feels like good design to eliminate/reduce this type of problems i= f > possible. Especially if it is better security design at reasonable cost. As far as implementation complexity, it's a wash. You have to have some lon= g-term "state", which now must include the old verify_data. There's no way = around that. It's not that much different to add this to the calculation of the Finished= message, either in concatenation to the handshake messages, or instead of = the finished label, as it is to compare it to the contents of the RI extens= ion. There is the risk that an implementer who hasn't been following this list m= ight fail to verify the data in the extension. Googling 'security bug "fail= s to verify"' returns 34,000 hits, suggesting that this is a valid concern.= From mrex@sap.com Thu Nov 26 07:56:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429FD3A68F0 for ; Thu, 26 Nov 2009 07:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 kg0c6QynPQhO for ; Thu, 26 Nov 2009 07:56:06 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 4DF0A3A67FD for ; Thu, 26 Nov 2009 07:56:05 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQFtqCW010704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 16:55:52 +0100 (MET) From: Martin Rex Message-Id: <200911261555.nAQFtpNq006883@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Thu, 26 Nov 2009 16:55:51 +0100 (MET) In-Reply-To: <6b9359640911260033q4eee63f3sb43aa76c657453b7@mail.gmail.com> from "Kyle Hamilton" at Nov 26, 9 00:33:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Other S->C signaling methods X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 15:56:07 -0000 Kyle Hamilton wrote: > > We've already heard that Microsoft IIS sends an extension in the case > of working with a particular cipher, even in the event that the client > didn't request the extension. (It contains the information necessary > to work with the cipher suite.) *I* didn't say that. There are two test TLS servers on the Internet that will return an unsolicited ServerHelloExtension when a particular cipher suite is negotiated. One of them replies with this: Server: Apache/1.3.34 (Debian) mod_ssl/2.8.25 OpenSSL/0.9.8e (I can't reach the other from our internal network). WinXP and W2K3 do not seem to allow sending ClientHelloExtensions to Cryptographic Service Providers, but it seems that _somehow_ they allow to receive unsolicited ServerHelloExtensions. -Martin From uri@ll.mit.edu Thu Nov 26 08:09:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4113A68CE for ; Thu, 26 Nov 2009 08:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umf+KF8bWreK for ; Thu, 26 Nov 2009 08:09:01 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id DF2853A685D for ; Thu, 26 Nov 2009 08:09:00 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAQG8q5m013302 for ; Thu, 26 Nov 2009 11:08:52 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAN2aGcy; Thu Nov 26 11:04:37 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Thu, 26 Nov 2009 11:04:37 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "tls@ietf.org" Date: Thu, 26 Nov 2009 11:04:35 -0500 Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: AcpuWx2lazcgN8TIQP+CRpO4nW5MNgAVwgaJ Message-ID: In-Reply-To: <4B0E1501.5080002@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 16:09:01 -0000 Yes, previous_verify_data MUST be a part of the input to the PRF. What Yoav Nir said (XOR-ing it with the master_secret), should work (out of hand - anybody sees a problem with it?). What David-Sarah said, but you could XOR it with the master_secret as input to the PRF, or even better, use it instead of the finished_label. On 11/26/09 00:41 , "David-Sarah Hopwood" wrote: > Michael D'Errico wrote: >>> Eric Rescorla wrote: >>>=20 >>>>> 3) Incorporate previous verify_data into Finished calc. >>>>=20 >>>> I'm not happy with this, actually. >>=20 >> Would this work: >>=20 >> Finished =3D verify_data XOR previous_verify_data >=20 > No. The previous_verify_data has to be in the input to the PRF > that also depends on the master_secret. If you just XOR it to > the output, then the attacker doesn't need to know the master_secret > in order to change the unmodified Finished to the modified one. --=20 Regards, Uri From root@core3.amsl.com Thu Nov 26 08:15:02 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 59DA63A6A69; Thu, 26 Nov 2009 08:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091126161502.59DA63A6A69@core3.amsl.com> Date: Thu, 26 Nov 2009 08:15:02 -0800 (PST) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-renegotiation-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 16:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Renegotiation Indication Extension Author(s) : E. Rescorla, et al. Filename : draft-ietf-tls-renegotiation-01.txt Pages : 10 Date : 2009-11-26 SSL and TLS renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This draft defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 30, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-renegotiation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-26081456.I-D@ietf.org> --NextPart-- From ekr@networkresonance.com Thu Nov 26 08:17:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33DD3A68FC for ; Thu, 26 Nov 2009 08:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.121 X-Spam-Level: X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEkUgH3+8Y2z for ; Thu, 26 Nov 2009 08:17:39 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 571733A684D for ; Thu, 26 Nov 2009 08:17:39 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id A30A96C36F7; Thu, 26 Nov 2009 08:18:12 -0800 (PST) Date: Thu, 26 Nov 2009 08:18:11 -0800 From: Eric Rescorla To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3113E20C@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091125223502.4265B6C3285@kilo.networkresonance.com> <808FD6E27AD4884E94820BC333B2DB774F3113E20C@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091126161812.A30A96C36F7@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 16:17:40 -0000 At Thu, 26 Nov 2009 08:03:48 +0100, > Unless the WG believes these goals are not actually met (that is, this > still could break too many things, or is excessively complex to > implement/deploy), I'd like to see an updated draft soon, and start > IETF Last Call. I've just submitted an updated draft with this change. -Ekr From mrex@sap.com Thu Nov 26 08:18:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2903A6A82 for ; Thu, 26 Nov 2009 08:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 F4rDiHQcGHsw for ; Thu, 26 Nov 2009 08:18:00 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 01BFF3A684C for ; Thu, 26 Nov 2009 08:17:59 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQGHrOu013373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 17:17:53 +0100 (MET) From: Martin Rex Message-Id: <200911261617.nAQGHq8I008139@fs4113.wdf.sap.corp> To: uri@ll.mit.edu (Blumenthal, Uri - 0662 - MITLL) Date: Thu, 26 Nov 2009 17:17:52 +0100 (MET) In-Reply-To: from "Blumenthal, Uri - 0662 - MITLL" at Nov 26, 9 11:04:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 16:18:01 -0000 I would really prefer the previous_verify_data to be covered by the signature of the ClientVerify message. It would be OK for me to add the verify_data of the Client.Finished message to the renegotiation handshake before the ClientHello (but the Server.Finished needs to go later, so that the handshake roundtrip optimization is not killed by this). -Martin Blumenthal, Uri - 0662 - MITLL wrote: > > Yes, previous_verify_data MUST be a part of the input to the PRF. What Yoav > Nir said (XOR-ing it with the master_secret), should work (out of hand - > anybody sees a problem with it?). > > What David-Sarah said, but you could XOR it with > the master_secret as input to the PRF, or even better, > use it instead of the finished_label. From uri@ll.mit.edu Thu Nov 26 08:21:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611493A6A82 for ; Thu, 26 Nov 2009 08:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGDeyYdWIvRU for ; Thu, 26 Nov 2009 08:21:45 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 884BC3A684C for ; Thu, 26 Nov 2009 08:21:45 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAQGLdUj015890; Thu, 26 Nov 2009 11:21:39 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAA71airE; Thu Nov 26 11:20:19 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Thu, 26 Nov 2009 11:20:19 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "mrex@sap.com" Date: Thu, 26 Nov 2009 11:20:17 -0500 Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: AcputAfsbI3vycWMT4+4pCDVzSW6jwAAE9Mf Message-ID: In-Reply-To: <200911261617.nAQGHq8I008139@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 16:21:46 -0000 On 11/26/09 11:17 , "Martin Rex" wrote: > I would really prefer the previous_verify_data to be covered by the > signature of the ClientVerify message. One does not exclude the other, does it? > It would be OK for me to add the verify_data of the Client.Finished > message to the renegotiation handshake before the ClientHello > (but the Server.Finished needs to go later, so that the > handshake roundtrip optimization is not killed by this). >=20 > Blumenthal, Uri - 0662 - MITLL wrote: >>=20 >> Yes, previous_verify_data MUST be a part of the input to the PRF. What Y= oav >> Nir said (XOR-ing it with the master_secret), should work (out of hand - >> anybody sees a problem with it?). >>=20 >> What David-Sarah said, but you could XOR it with >> the master_secret as input to the PRF, or even better, >> use it instead of the finished_label. --=20 Regards, Uri uri@ll.mit.edu From marsh@extendedsubset.com Thu Nov 26 08:33:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E5A3A6978 for ; Thu, 26 Nov 2009 08:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 neB7JNmgtqTN for ; Thu, 26 Nov 2009 08:33:21 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 0F8763A6861 for ; Thu, 26 Nov 2009 08:33:21 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDhHP-000KUa-4a; Thu, 26 Nov 2009 16:33:15 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F2391603A; Thu, 26 Nov 2009 16:33:11 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19mc4gNyiOPvCX3vVS5DLA/Wyl+l3AJF4E= Message-ID: <4B0EADC6.4070306@extendedsubset.com> Date: Thu, 26 Nov 2009 10:33:10 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David-Sarah Hopwood References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <4B0DBB97.5050500@pobox.com> <4B0DFB03.5020201@pobox.com> <4B0E1501.5080002@jacaranda.org> In-Reply-To: <4B0E1501.5080002@jacaranda.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 16:33:21 -0000 David-Sarah Hopwood wrote: > Michael D'Errico wrote: >>> Eric Rescorla wrote: >>> >>>>> 3) Incorporate previous verify_data into Finished calc. >>>> I'm not happy with this, actually. >> Would this work: >> >> Finished = verify_data XOR previous_verify_data > > No. The previous_verify_data has to be in the input to the PRF > that also depends on the master_secret. If you just XOR it to > the output, then the attacker doesn't need to know the master_secret > in order to change the unmodified Finished to the modified one. If I understand it correctly, Mitm could decrypt the renegotiated Finished message record, modify it, and re-encrypt it. Effectively this means the authentication and integrity guarantees on protocol could be no stronger than the encryption. That could be a significant weakening of the protocol's security. Another attack would require Mitm to arrange for an arbitrary Finished message on the previous session. In order to do that he would have to a) know ahead of time what value to construct and b) succeed at a first preimage attack on the hash function represented by 12 bytes from the PRF Pulling off (a) would be hard because of the unpredictable random_data bytes in the other side's Hello message. (b) would mean the protocol was so broken that he wouldn't need renegotiation to compromise it. It's worth noting here that this hash output is 96 bits. The NIST hash selection process for the successor to SHA requires a minimum output size of 224 bits. - Marsh From marsh@extendedsubset.com Thu Nov 26 09:10:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A37C3A6920 for ; Thu, 26 Nov 2009 09:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 C92RVRbx-uoS for ; Thu, 26 Nov 2009 09:10:41 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 3B9763A6A96 for ; Thu, 26 Nov 2009 09:10:41 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDhrV-0003FL-Vc; Thu, 26 Nov 2009 17:10:34 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B34A2603A; Thu, 26 Nov 2009 17:10:31 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18D+Mqm3jLnwQtjggLRRQ8Wr0SilXF11Ek= Message-ID: <4B0EB686.4090905@extendedsubset.com> Date: Thu, 26 Nov 2009 11:10:30 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yoav Nir References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> In-Reply-To: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: [TLS] Perhaps there's another way. Was: Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:10:45 -0000 Yoav Nir wrote: > > As far as implementation complexity, it's a wash. You have to have > some long-term "state", which now must include the old verify_data. > There's no way around that. Perhaps, but that state does not need to be more that a bit or two in each direction for the signaling. State derived from the previous handshake is already available at both endpoints. It is not necessary to carry over more! This state currently resides in: client write MAC secret server write MAC secret client write key server write key These secure entropy within these parameters are considered sufficient to protect all the application data, why aren't they good enough to establish continuity-of-identity across the renegotiation? Seems to me the MAC_secret is better than the Finished message if for no other reason than it's 20 bytes instead of 12. Currently, all this hard-won entropy is discarded at the CCS. A tragedy! My proposal: At the CCS, instead of replacing the client/server MAC secret data, simply XOR-merge the incoming values with the previous ones. * A one-line software change. * Easy even in hardware. * Preserves more entropy. * No changes to PRF. Please actively attempt to shoot it down. - Marsh From djhopwood@googlemail.com Thu Nov 26 09:24:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC753A6A85 for ; Thu, 26 Nov 2009 09:24:43 -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 04tz+oHTx0cz for ; Thu, 26 Nov 2009 09:24:42 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id E32293A6893 for ; Thu, 26 Nov 2009 09:24:41 -0800 (PST) Received: by bwz23 with SMTP id 23so715650bwz.29 for ; Thu, 26 Nov 2009 09:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=qzUGRFIctLh5M6STZxdbGQlZiLVGXps6q1SoUh0nFZ8=; b=Xb05yEXnMonD1kQppv1i98IWPO2hxbQko/xcBp9GrD+mjiUSxIAeEmbhBYjcjZsRMg 16WO3t1QPL1f4tw/XNNuMO7ApLCIbj0MYNwrngwq3GVWqZRaL8KYxn6DBkDFYb/ova3T BRXAuKHIpIK5uHChszOq+di/xhWvLM1M9Wi98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Dl+boz7kbvYwz7/rTcqNjRPDR1qtLITaIxuxq4uk2204xw5R50D8lX7YnS/zXYXoYE 2Of0IBqggx1ZC3c6IOaI9DjF0jCBK69FISVPB51SAK1jJN/165ZBjCbH8DNf43FCcfr/ WgsAoMh+qT+gfku3bTcoVCcjrFCIY1qzwSgXk= Received: by 10.204.155.65 with SMTP id r1mr138543bkw.143.1259256191039; Thu, 26 Nov 2009 09:23:11 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id d13sm1172371fka.47.2009.11.26.09.23.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 09:23:09 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0EB97A.6010106@jacaranda.org> Date: Thu, 26 Nov 2009 17:23:06 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig71C97ED84B9B1EEF608BFF78" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:24:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig71C97ED84B9B1EEF608BFF78 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blumenthal, Uri - 0662 - MITLL wrote: > Yes, previous_verify_data MUST be a part of the input to the PRF. What = Yoav > Nir said (XOR-ing it with the master_secret), should work (out of hand = - > anybody sees a problem with it?). The previous_verify_data is not necessarily secret, so this requires the PRF to be secure against related-key attack. The particular PRFs used in SSLv3 and TLS 1.0 to 1.2 should be secure in that sense, but (if we decide to use this approach) I still prefer what I suggested before: verify_data =3D PRF(master_secret, finished_label, Hash(handshake_messages) + previous_verify_data) [0..verify_data_length-1]; which uses the PRF in a more conventional way. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig71C97ED84B9B1EEF608BFF78 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksOuYsACgkQWUc8YzyzqAcPHwD/V9dlRHO8HnODorQOyk1XTQYP +CBzNTSXLKHBTZ7r/WkA/2FIHDl+ummLIBLWHCuaRsuFHVLlHoPX60o3qCuEY8e2 =gjul -----END PGP SIGNATURE----- --------------enig71C97ED84B9B1EEF608BFF78-- From lists@drh-consultancy.demon.co.uk Thu Nov 26 09:27:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FFB3A6A9B for ; Thu, 26 Nov 2009 09:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 R7oy7-lwDOea for ; Thu, 26 Nov 2009 09:27:36 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by core3.amsl.com (Postfix) with ESMTP id 808A63A6893 for ; Thu, 26 Nov 2009 09:27:36 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49737 helo=[192.168.7.8]) by relay01.mail.eu.clara.net (relay.clara.net [213.253.3.41]:10587) with esmtpa (authdaemon_plain:drh) id 1NDi7t-00063Y-41 (Exim 4.69) for tls@ietf.org (return-path ); Thu, 26 Nov 2009 17:27:29 +0000 Message-ID: <4B0EBA86.9010107@drh-consultancy.demon.co.uk> Date: Thu, 26 Nov 2009 17:27:34 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <4B0EB686.4090905@extendedsubset.com> In-Reply-To: <4B0EB686.4090905@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Perhaps there's another way. Was: Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:27:38 -0000 Marsh Ray wrote: > Yoav Nir wrote: >> As far as implementation complexity, it's a wash. You have to have >> some long-term "state", which now must include the old verify_data. >> There's no way around that. > > Perhaps, but that state does not need to be more that a bit or two in > each direction for the signaling. > > State derived from the previous handshake is already available at both > endpoints. It is not necessary to carry over more! > > This state currently resides in: > client write MAC secret > server write MAC secret > client write key > server write key > > These secure entropy within these parameters are considered sufficient > to protect all the application data, why aren't they good enough to > establish continuity-of-identity across the renegotiation? > > Seems to me the MAC_secret is better than the Finished message if for no > other reason than it's 20 bytes instead of 12. Currently, all this > hard-won entropy is discarded at the CCS. A tragedy! > > My proposal: > > At the CCS, instead of replacing the client/server MAC secret data, > simply XOR-merge the incoming values with the previous ones. > > * A one-line software change. > * Easy even in hardware. > * Preserves more entropy. > * No changes to PRF. > > Please actively attempt to shoot it down. > I think this will give problems for external crypto libraries like PKCS#11 where session key derivation is a mechanism with fixed parameters and the actual keys are not available in plain text outside the hardware. You'd need to develop a new mechanism, add it to the PKCS#11 spec and update firmware on every piece of crypto hardware. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From stefan@aaa-sec.com Thu Nov 26 09:34:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF383A6A9D for ; Thu, 26 Nov 2009 09:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bavGXXOu8f2T for ; Thu, 26 Nov 2009 09:34:43 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 777FF3A6893 for ; Thu, 26 Nov 2009 09:34:42 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 16BF028E446 for ; Thu, 26 Nov 2009 18:34:42 +0100 (CET) Received: (qmail 69341 invoked from network); 26 Nov 2009 17:34:35 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Nov 2009 17:34:35 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 26 Nov 2009 18:34:33 +0100 From: Stefan Santesson To: Eric Rescorla , Message-ID: Thread-Topic: [TLS] Avoiding first use of RI in ClientHello Thread-Index: Acpuvrc0UVkTKl7F80GNEIeeiJ1abA== In-Reply-To: <20091126161812.A30A96C36F7@kilo.networkresonance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:34:44 -0000 Reading the draft I realize I misunderstood one aspect. I don't understand the benefit from having different signaling in the initial handshakes and renegotiation handshakes. Especially since I think it is better security design to not send the verify data from previous handshakes. Do you think sending the verify data is better security design? And why? /Stefan On 09-11-26 5:18 PM, "Eric Rescorla" wrote: > At Thu, 26 Nov 2009 08:03:48 +0100, >> Unless the WG believes these goals are not actually met (that is, this >> still could break too many things, or is excessively complex to >> implement/deploy), I'd like to see an updated draft soon, and start >> IETF Last Call. > > I've just submitted an updated draft with this change. > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Chris.Newman@Sun.COM Thu Nov 26 09:44:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9509A28C113 for ; Thu, 26 Nov 2009 09:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 1wDJXlc+BG9R for ; Thu, 26 Nov 2009 09:44:14 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 4C8833A67E4 for ; Thu, 26 Nov 2009 09:44:14 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAQHi7aR014444 for ; Thu, 26 Nov 2009 09:44:07 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTQ0050097H4S00@fe-sfbay-10.sun.com> for tls@ietf.org; Thu, 26 Nov 2009 09:44:07 -0800 (PST) Received: from vpn-129-150-242-97.sfbay.sun.com ([unknown] [71.92.75.71]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTQ0041699GJ000@fe-sfbay-10.sun.com>; Thu, 26 Nov 2009 09:44:06 -0800 (PST) Date: Thu, 26 Nov 2009 09:43:29 -0800 From: Chris Newman In-reply-to: <200911210002.nAL02CEx007574@fs4113.wdf.sap.corp> Sender: Chris.Newman@Sun.COM To: mrex@sap.com Message-id: <8D2529C4D76F7E4B2AC769A4@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <200911210002.nAL02CEx007574@fs4113.wdf.sap.corp> Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:44:15 -0000 --On November 21, 2009 1:02:12 +0100 Martin Rex wrote: > Chris Newman wrote: >> >> --On November 19, 2009 22:23:43 +0100 Martin Rex wrote: >> > Asking SSLv3 implementations to improve on their extensions-intolerance >> > is still OK. Requiring them to implement generic TLS extensions >> > is not, because it has nothing to do with the problem and is >> > an unnecessary complexity for the fix. >> >> What if we require SSLv3 compatible clientHello and SSLv3 serverHello to >> list RI first and at least ignore additional extensions, waiving the >> requirement for full extension support for SSLv3-only implementations? > > I don't see how this would solve the problem. This would solve the problem of SSLv3-only implementations that must be upgraded to address this issue being difficult to upgrade to full TLS with general extensions support. That's a problem I believe may be worth solving for this particular security vulnerability. It also addresses the very real problem that having two ways to negotiate the same thing is bad design and there have been proposals to negotiate via different protocol elements in SSLv3 than in TLS. > How to you interoperate with installed base SSLv3 and TLSv1.0 that > is extensions-intolerant without being vulnerable to downgrade attacks? The alleged extensions-intolerant servers were broken when they were first released and it is unfortunate their failure to comply with standards was not identified and fixed sooner. Since they must be upgraded to either be made secure or identified as secure, why not fix the standards-compliance bug (failure to tolerate extensions) at the same time? Seems a lot cleaner and safer than kludging crap into critical fields in the ServerHello. So this is a problem that I do not consider worth solving -- indeed I prefer solutions that break implementations that already demonstrated an inability to follow published standards. As a pragmatist, I'd consider an exception if a particular implementation was widely deployed and difficult to upgrade, but we'd need to see a list of these non-compliant servers to make that evaluation. If nobody is motivated enough to produce that list, I assume none of them are problematic. - Chris From djhopwood@googlemail.com Thu Nov 26 09:46:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C053A6A9C for ; Thu, 26 Nov 2009 09:46:50 -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 JEIjlV+LUsiG for ; Thu, 26 Nov 2009 09:46:49 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 914EE3A67E4 for ; Thu, 26 Nov 2009 09:46:48 -0800 (PST) Received: by ewy6 with SMTP id 6so1032582ewy.29 for ; Thu, 26 Nov 2009 09:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=HgeJCeno9ZMBg26a1mZKiTg8j2iMtIKK2NxWOGaRqFo=; b=qQUuVr/DZtRokJ0Irgs0DEm0ZlhsiKbqsu592TwlzYEojmPEkwWJpQEO2A3g0vsDvE CsxT8STYQp9EbFMkWk+y9+Q3c9FfmOTt3yeae/Vqik9IK18vlXMPx1oqtr4Q5wmTHmY9 04h3xAwVUajXf1h39zH8G8TLMolBwTEeu2p78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=sAfkb0Y0OIhMMBqPvNK7hwYY1A0UQUC/uW5GDPv8M/rV1L2IekW4zo+o+wfSMNDgx7 zqzc0Xq04MkP3HtTtRylD/rvZWn3bh5hhjRXvE1GCCcQYezLtp4BG5QAOaVttdLbkbuK i0PuvQQ2vBklX8fweUlcroOdd98sawRewTYJw= Received: by 10.213.0.216 with SMTP id 24mr1161229ebc.10.1259257599072; Thu, 26 Nov 2009 09:46:39 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 16sm444928ewy.6.2009.11.26.09.46.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 09:46:38 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0EBF04.7090708@jacaranda.org> Date: Thu, 26 Nov 2009 17:46:44 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911260735.nAQ7ZbYP003893@fs4113.wdf.sap.corp> In-Reply-To: <200911260735.nAQ7ZbYP003893@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8137181FFBC3C758BD721598" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:46:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8137181FFBC3C758BD721598 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > David-Sarah Hopwood wrote: >> The old verify_data should not just be appended to the handshake_messa= ges >> without any further encoding, though, because it might match the bytes= >> of some valid handshake message. In that case, there is the possibilit= y >> that a MITM might insert the old verify_data into the stream sent to >> one peer, as though it were a handshake message. If that peer is using= >> the unmodified Finished computation (either because it is unpatched or= >> it is doing an initial handshake), then it may end up computing the sa= me >> Finished hash as the other peer that is using the modified computation= =2E >> >> I haven't gone through the details of this attack thoroughly enough >> to be sure it will work, but it is too near working for comfort. >=20 > OK. you got a point! >=20 > It's true that there is a theoretical attack. >=20 > So Mikes idea to always add a length to the hash > (and therefore also change the initial handshake between > updated peers) was not so bad after all. >=20 >> 2. Add the old verify_data to handshake_messages preceded by the encod= ing >> of a fatal alert. Then, attacks of the kind described above can't w= ork >> because the unpatched peer would first process the alert and abort = the >> handshake. >=20 > Alerts are no handshake messages, so that doesn't work. You're right, the attacker could just omit the alert. > different possibilities: > - add a bodyless-finished message to the beginning of the handshake > message hash of a secure renegotiation before the ClientHello > a position where the attacker can not insert handshake messages It's not clear to me that the attacker can't insert handshake messages there. If an implementation normally ignores handshake messages with an unrecognized HandshakeType, then it is likely to ignore them before the ClientHello as well. For a random 24-byte string, the HandshakeType has a 246 in 256 ~=3D 96% probability of being unrecognized, but then the length is a uint24, and the attacker needs it to encode the number 20 in order for the attack to work as I described it. So this attack almost certainly isn't practical, but we should be sure to prevent it rather than relying on probabilities. > - add something different to both handshake message hashes > before adding the verify_data to the renegotiation handshake > message hash > - frame the Client.Finished.verify_data plus > Server.Finished.verify_data as a Finished message > - signal initial and renegotiation handshakes differently in the > handshake I'll have to think about these more carefully. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig8137181FFBC3C758BD721598 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksOvwsACgkQWUc8YzyzqAeoWgD/damkXf50PiS4D8sjwjH7Ra1V Jkqi3gIO1h775ImG0l8BAJJb5O6JAw4SOpjegYW+wWGo7m6PR9wz8lK/9D+DWB9e =CQOk -----END PGP SIGNATURE----- --------------enig8137181FFBC3C758BD721598-- From yaronf@checkpoint.com Thu Nov 26 09:55:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05863A6893 for ; Thu, 26 Nov 2009 09:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEwJsXl+UH6v for ; Thu, 26 Nov 2009 09:55:20 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 1EE2E3A67E4 for ; Thu, 26 Nov 2009 09:55:19 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAQHt5Go017169 for ; Thu, 26 Nov 2009 19:55:05 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 26 Nov 2009 19:55:11 +0200 From: Yaron Sheffer To: "tls@ietf.org" Date: Thu, 26 Nov 2009 19:55:09 +0200 Thread-Topic: Server-only solution - proposed text Thread-Index: AcpsHrQfc2dpXjJbQye8ntQsVgpoVgColWnw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0344@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0344ilex01adche_" MIME-Version: 1.0 Subject: Re: [TLS] Server-only solution - proposed text X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:55:23 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0344ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I proposed this text earlier this week. It did not make its way into draft = -01, and I think it's important enough to reiterate. We should allow server= administrators some freedom in setting their own policy, "just saying no" = is not a good option. Thanks, Yaron ________________________________ From: Yaron Sheffer Sent: Monday, November 23, 2009 11:24 To: 'tls@ietf.org' Subject: Server-only solution - proposed text Hi, Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin's I= -D-to-be) are making changes to the protocol, and therefore will only becom= e effective once a good percentage of clients have been patched. In the mea= ntime, administrators could fix their (patched) servers locally in many cas= es, without waiting for the client population to get fixed. I propose to ad= d the following short section to both drafts: X. Server-Side Mitigation Procedures We assume that it will take a significant amount of time until the protocol= change defined in this document is adopted by all clients. However, in man= y cases a server-only mitigation is possible in the interim: many TLS appli= cations, and in particular, many Web (HTTPS) applications, do not require r= enegotiation for proper operation. Implementations of the current document = (unless they employ a strict policy, allowing only protected clients to con= nect) SHOULD be configurable to disallow TLS renegotiation with vulnerable = clients. The following three settings are RECOMMENDED: - Allow any renegotiation with unprotected clients. - Allow only server-initiated renegotiation with unprotected clients. - Disallow renegotiation with unprotected clients.. The default setting is a matter of vendor and/or local policy. [Note: this contradicts the sentence "Servers SHOULD NOT allow clients to r= enegotiate without using this extension" in the Security Considerations of = draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be foll= owed by many implementers.] Thanks, Yaron --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0344ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I proposed this text earlier this week= . It did not make its way into draft -01, and I think it’s important enoug= h to reiterate. We should allow server administrators some freedom in setting th= eir own policy, “just saying no” is not a good option.

 

Thanks,

      &n= bsp;     Yaron

 

From: Yaron Sheffer
Sent: Monday, November 23, 2= 009 11:24
To: 'tls@ietf.org'
Subject: Server-only solutio= n - proposed text

 

Hi,

 

Both proposals on the table (draft-ietf-tls-renegotiatio= n-00 and Martin’s I-D-to-be) are making changes to the protocol, and there= fore will only become effective once a good percentage of clients have been patc= hed. In the meantime, administrators could fix their (patched) servers locally i= n many cases, without waiting for the client population to get fixed. I propo= se to add the following short section to both drafts:=

 

X. Server-Side Mitigation Procedures

 

We assume that it will take a significant amount of time until the protocol change defined in this document is adopted by all client= s. However, in many cases a server-only mitigation is possible in the interim: many TLS applications, and in particular, many Web (HTTPS) applications, do= not require renegotiation for proper operation. Implementations of the current document (unless they employ a strict policy, allowing only protected clien= ts to connect) SHOULD be configurable to disallow TLS renegotiation with vulnerable clients. The following three settings are RECOMMENDED:

 

-       Allow any renegotiation with unprotected clients.

-       Allow only server-initiated renegotiation with unprotected clients.<= /font>

-       Disallow renegotia= tion with unprotected clients..

 

The default setting is a matter of vendor and/or local policy.

 

[Note: this contradicts the sentence “Servers SHOU= LD NOT allow clients to renegotiate without using this extension” in the Security Considerations of draft-ietf-tls-renegotiation-00, which unfortuna= tely is unlikely to be followed by many implementers.]<= /p>

 

Thanks,

         &n= bsp;  Yaron

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0344ilex01adche_-- From mrex@sap.com Thu Nov 26 10:01:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3B33A689C for ; Thu, 26 Nov 2009 10:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 oHO-24n+cyfs for ; Thu, 26 Nov 2009 10:01:57 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 28D143A67E4 for ; Thu, 26 Nov 2009 10:01:56 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQI1o6c022242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 19:01:50 +0100 (MET) From: Martin Rex Message-Id: <200911261801.nAQI1nCd015456@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 26 Nov 2009 19:01:49 +0100 (MET) In-Reply-To: <4B0EB97A.6010106@jacaranda.org> from "David-Sarah Hopwood" at Nov 26, 9 05:23:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:01:58 -0000 David-Sarah Hopwood wrote: > > The previous_verify_data is not necessarily secret, so this requires the > PRF to be secure against related-key attack. The particular PRFs used in > SSLv3 and TLS 1.0 to 1.2 should be secure in that sense, but (if we > decide to use this approach) I still prefer what I suggested before: > > verify_data = > PRF(master_secret, finished_label, Hash(handshake_messages) > + previous_verify_data) > [0..verify_data_length-1]; > > which uses the PRF in a more conventional way. I strongly recommend against such an approach. It's going to be a big mess implementation-wise. You'll have to keep double the state around in order to be able to calculate the Server.Finished of the Renegotiation, and then transfer shift the oldest verify_data out after Server.Finished. It's more code, it doesn't address the CertificateVerify at all and to interop-test this reliably, you will need to perform at least two rengotiations on a communication channel to be sure that the shifting of the Finished messages works correctly. Most implementations that offer renegotiation do not have usage scenarios to test dual-renegotiations, requiring additional test tools to be built. One of the reasons why I wanted to add the verify_data early into the handshake is that the session only needs to provide room for one of them, making it much easier to implement when you don't have to special case around while calculating the finished messages and temporarilyy parking of the new Client.Finished before the new Server.Finished processing has completed. I think that adding the Client.Finished.verify_data at the very beginning of a renegotiation handshake message hash, maybe even prefixed with a bogus Finished message header 0x14 0x00 0x00 0x77 would address the theoretical attack that you brought up. -Martin From mike-list@pobox.com Thu Nov 26 10:05:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C433A6861 for ; Thu, 26 Nov 2009 10:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nACwOcsd+12k for ; Thu, 26 Nov 2009 10:05:10 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 7E2793A67E4 for ; Thu, 26 Nov 2009 10:05:07 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B9223A1567 for ; Thu, 26 Nov 2009 13:05:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=BEDzY8rFwmQc sLuxKST0gb9rhfA=; b=FLZnxGu54mkEKqn1rYmNVNZmw/8idMvV+YjflOJMLREu G8mb553x/TYfCU4bLuhXU7U1TiH7g9lxuPQ8lV/1HUMxb9UFrWeIU7KgonUh6ckG TE2BwYkwnoVkhMS1s4rT7NOribX8PTmhLFHSIzm3GBlrJO86SnzI28vrJ/pPZps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=AM4QIF BP4FWcrwfCZsfvjMLZLgU4oRAMd3fZlHIl+0IGFRxidir4jDvW0qf548m6ZIvYEa u5FGsdbmatREbOKXUn1v+NgWPPoamreYGrJkg3lEe9R2ABe9LmKX/vhemRqqk/eg eROx1L6lkECpd3swdmCJ+XBSoVORemFLMHpA4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 78F90A1566 for ; Thu, 26 Nov 2009 13:05:01 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 19511A1564 for ; Thu, 26 Nov 2009 13:05:00 -0500 (EST) Message-ID: <4B0EC393.6090202@pobox.com> Date: Thu, 26 Nov 2009 10:06:11 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B0EB97A.6010106@jacaranda.org> In-Reply-To: <4B0EB97A.6010106@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 374DDD5E-DAB6-11DE-A94A-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:05:11 -0000 There are a couple problems with changing the PRF: 1) there is no PRF in SSLv3 2) CertificateVerify is just a signature over the handshake messages The idea of XOR'ing the verify_data with the master_secret would work in SSLv3 (1), but would not help with (2). Is (2) really important since the entire handshake is verified upon the exchange of Finished messages? Mike David-Sarah Hopwood wrote: > Blumenthal, Uri - 0662 - MITLL wrote: >> Yes, previous_verify_data MUST be a part of the input to the PRF. What Yoav >> Nir said (XOR-ing it with the master_secret), should work (out of hand - >> anybody sees a problem with it?). > > The previous_verify_data is not necessarily secret, so this requires the > PRF to be secure against related-key attack. The particular PRFs used in > SSLv3 and TLS 1.0 to 1.2 should be secure in that sense, but (if we > decide to use this approach) I still prefer what I suggested before: > > verify_data = > PRF(master_secret, finished_label, Hash(handshake_messages) > + previous_verify_data) > [0..verify_data_length-1]; > > which uses the PRF in a more conventional way. From uri@ll.mit.edu Thu Nov 26 10:12:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188AF3A6A80 for ; Thu, 26 Nov 2009 10:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R+V4dBFtrig for ; Thu, 26 Nov 2009 10:12:39 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 0C4CF3A6935 for ; Thu, 26 Nov 2009 10:12:38 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAQICX6e007817 for ; Thu, 26 Nov 2009 13:12:33 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAKNay2o; Thu Nov 26 13:11:43 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Thu, 26 Nov 2009 13:11:43 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "tls@ietf.org" Date: Thu, 26 Nov 2009 13:11:35 -0500 Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: AcpuvVua4YGF8PHnQiWH86Ud9iSoeQABogF+ Message-ID: In-Reply-To: <4B0EB97A.6010106@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:12:40 -0000 I forgot about that. Good point. I agree. As for SSLv3 - SMNP (Simply Not My Problem :). Would be nice to address it as well, but I'd rather not bend over backwards to also fix SSLv3. On 11/26/09 12:23 , "David-Sarah Hopwood" wrote: > Blumenthal, Uri - 0662 - MITLL wrote: >> Yes, previous_verify_data MUST be a part of the input to the PRF. What Y= oav >> Nir said (XOR-ing it with the master_secret), should work (out of hand - >> anybody sees a problem with it?). >=20 > The previous_verify_data is not necessarily secret, so this requires the > PRF to be secure against related-key attack. The particular PRFs used in > SSLv3 and TLS 1.0 to 1.2 should be secure in that sense, but (if we > decide to use this approach) I still prefer what I suggested before: >=20 > verify_data =3D > PRF(master_secret, finished_label, Hash(handshake_messages) > + previous_verify_data) > [0..verify_data_length-1]; >=20 > which uses the PRF in a more conventional way. --=20 Regards, Uri uri@ll.mit.edu From mrex@sap.com Thu Nov 26 10:21:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B715C28C150 for ; Thu, 26 Nov 2009 10:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 D9OsgQszpJ7S for ; Thu, 26 Nov 2009 10:21:17 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 8C91428C149 for ; Thu, 26 Nov 2009 10:21:17 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQILBZa007337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 19:21:11 +0100 (MET) From: Martin Rex Message-Id: <200911261821.nAQILA6p016658@fs4113.wdf.sap.corp> To: Chris.Newman@Sun.COM (Chris Newman) Date: Thu, 26 Nov 2009 19:21:10 +0100 (MET) In-Reply-To: <8D2529C4D76F7E4B2AC769A4@446E7922C82D299DB29D899F> from "Chris Newman" at Nov 26, 9 09:43:29 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:21:18 -0000 Chris Newman wrote: > > It also addresses the very real problem that having two ways to negotiate > the same thing is bad design and there have been proposals to negotiate via > different protocol elements in SSLv3 than in TLS. This was one of my biggest complaints all the time. I want only one single solution for SSLv3->TLSv1.2, because it is exactly the same problem affecting the entire installed base. > > > How to you interoperate with installed base SSLv3 and TLSv1.0 that > > is extensions-intolerant without being vulnerable to downgrade attacks? > > The alleged extensions-intolerant servers were broken when they were first > released and it is unfortunate their failure to comply with standards was > not identified and fixed sooner. There are still SSLv3 servers around, and as I've recently learned, the original Netscape SSLv3 spec did not provide for TLS extensions, Netscape offered the extensions-intolerant SSLv3 spec much more prominently than the SSLv3 document that was created in the TLS WG, and unfortunately the TLS WG never cared to publish the forward-compatible extensions-tolerant SSLv3-spec as an informational RFC. If anyone is to blame that the situation is as bad as it is concerning TLS-extensions interop, then it is certainly the IETF TLS WG that didn't care about it for _MANY_ years. RFC-5246 Appendix E clearly shows the attitude: there exist workarounds to address the interop problem, that's good enough. we don't care. > Since they must be upgraded to either be > made secure or identified as secure, why not fix the standards-compliance > bug (failure to tolerate extensions) at the same time? Seems a lot cleaner > and safer than kludging crap into critical fields in the ServerHello. Many of those that we want to upgrade might not actually be vulnerable (at least not in such a serious fashion as some webservers). So if you want them to consider patching their software, offending them or making the patch unnecessarily complex is definitely not going to help improve the situation. > > So this is a problem that I do not consider worth solving -- indeed I > prefer solutions that break implementations that already demonstrated an > inability to follow published standards. If you do that for new protocol versions, that's fine. The market will decide whether it needs a fubar-ed standard or not. Implementing the standars correctly didn't save anyone from the need to patch now. But those who didn't follow the recommendation to support renegotiation do not have as much of a problem as the compliant ones right now. But when you're trying to fix something many years into the past, then _NOT_ breaking the installed base is imperative. The TLS WG produced 2 TLS protocol revisions after TLSv1.0 and a lot of surrounding documents -- instead of reviewing the security properties of TLSv1.0. That this bug has gone so long without being noticed and is now part of a huge amount of installed base, some of which is long out of maintenance but still in use. It is definitely not the consumers of the SSLv3/TLS technology which are to blame here. -Martin From djhopwood@googlemail.com Thu Nov 26 10:25:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9AA3A6AC4 for ; Thu, 26 Nov 2009 10:25:03 -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 zHS7ePatwvVD for ; Thu, 26 Nov 2009 10:25:03 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 93DD53A689A for ; Thu, 26 Nov 2009 10:25:02 -0800 (PST) Received: by ewy6 with SMTP id 6so1069032ewy.29 for ; Thu, 26 Nov 2009 10:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=gMN5JZjxwExBGb7ntY4KP9O30rEqHQ20GHqht7O8MBY=; b=OEEuJg/uvESqG/kqmHgWa7c/jKAZ0zxjnnTz1cZnV3bUPs43hVibmz9fdbjM8gWVBX Z8TxO6a/jSoJCO8i9c92PFd6IO8Zr9BMgmLhK5eZDBYExBJpxAIjnDxSkNwK4CBxJH1p PbdL70I8Ekomb2IbznwpeVmzE+VuhvVe6Abwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=E/Y7uTRSpkF9muSb7RE3Qrwh1altg7j900stJ6GcSvZGaHrPshcyONubgUg/ImrDRb p8OWxuDF8HVJxaLSeoRdKBO8QImfxP0NC+EysU7aOeh9LnDob5ZSsK6qN5UDSDtl1BGy oX8Mzqk+5/qhbUyYDLB+wLwvGwMnfUaJ2Pw8M= Received: by 10.213.0.195 with SMTP id 3mr31521ebc.81.1259259889859; Thu, 26 Nov 2009 10:24:49 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm463848ewy.8.2009.11.26.10.24.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 10:24:48 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0EC7F5.5050100@jacaranda.org> Date: Thu, 26 Nov 2009 18:24:53 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911260735.nAQ7ZbYP003893@fs4113.wdf.sap.corp> <4B0EBF04.7090708@jacaranda.org> In-Reply-To: <4B0EBF04.7090708@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBD773CC4970866EA77B5B82F" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:25:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD773CC4970866EA77B5B82F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Martin Rex wrote: >> different possibilities: >> - add a bodyless-finished message to the beginning of the handshake >> message hash of a secure renegotiation before the ClientHello >> a position where the attacker can not insert handshake messages >=20 > It's not clear to me that the attacker can't insert handshake messages > there. If an implementation normally ignores handshake messages with an= > unrecognized HandshakeType, then it is likely to ignore them before the= > ClientHello as well. The TLS spec doesn't seem to be very clear on whether handshake messages with an unrecognized HandshakeType must cause an error (section 7.4). Does anyone know what implementations actually do? > For a random 24-byte string, the HandshakeType has a 246 in 256 ~=3D 96= % > probability of being unrecognized, but then the length is a uint24, > and the attacker needs it to encode the number 20 in order for the > attack to work as I described it. So this attack almost certainly isn't= > practical, but we should be sure to prevent it rather than relying on > probabilities. Ah, but if the attacker makes ~17.5 million connections (which do not all have to be to the same site; just to any site that they might want to attack), then they can expect to get a previous_verify_data that matches the encoding of a handshake message of unrecognized type. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigBD773CC4970866EA77B5B82F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksOx/0ACgkQWUc8YzyzqAeXxQD+P95AexwM3e8rSV6/4ZY5PHEI ScQ/CvuvNzWX5a0/cOUA/jEf2KFOCQPvsvA1hIuNKwRKtR68a5rBxrAPhNzVvKg1 =QwcM -----END PGP SIGNATURE----- --------------enigBD773CC4970866EA77B5B82F-- From mrex@sap.com Thu Nov 26 10:32:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9893A6A88 for ; Thu, 26 Nov 2009 10:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 wqHBxoafvgj9 for ; Thu, 26 Nov 2009 10:32:01 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A68CD3A6801 for ; Thu, 26 Nov 2009 10:32:00 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQIVs1v016192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 19:31:54 +0100 (MET) From: Martin Rex Message-Id: <200911261831.nAQIVrqb017425@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 26 Nov 2009 19:31:53 +0100 (MET) In-Reply-To: <4B0EBF04.7090708@jacaranda.org> from "David-Sarah Hopwood" at Nov 26, 9 05:46:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:32:01 -0000 David-Sarah Hopwood wrote: > > > different possibilities: > > - add a bodyless-finished message to the beginning of the handshake > > message hash of a secure renegotiation before the ClientHello > > a position where the attacker can not insert handshake messages > > It's not clear to me that the attacker can't insert handshake messages > there. If an implementation normally ignores handshake messages with an > unrecognized HandshakeType, then it is likely to ignore them before the > ClientHello as well. ClientHello is the first handshake message on a connection that re-initialized the handshake message hash. If an implementation doesn't get that correct, then it is an obvious bug of the implementation. As an additional safety feature, the finished label for secure renegotiations could be modified. > > For a random 24-byte string, the HandshakeType has a 246 in 256 ~= 96% > probability of being unrecognized, but then the length is a uint24, > and the attacker needs it to encode the number 20 in order for the > attack to work as I described it. So this attack almost certainly isn't > practical, but we should be sure to prevent it rather than relying on > probabilities. I also believe it isn't practical to find a collision with a 24-byte correctly encoded no-op handshake message (i.e. one that does not adversly affect the handshake state), but if we can avoid it, we should avoid it. verify_data is not predictable, even for those TLS session where the MitM is an original server or client. Thanks for identifying this issue, even when it currently does not appear as a practical attack. explicitly inserting the header of a finished message (0x14 0x00 0x00 0x19) in front of the verify_data might help, because this is something that an attack does not want to insert after a ServerHello handshake message (oh yeah, one with an odd length field). -Martin From mike-list@pobox.com Thu Nov 26 10:35:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244BB3A68C4 for ; Thu, 26 Nov 2009 10:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 hE7idWJE5w+1 for ; Thu, 26 Nov 2009 10:35:32 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 49FDB3A6801 for ; Thu, 26 Nov 2009 10:35:32 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8850983964 for ; Thu, 26 Nov 2009 13:35:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=13YurkRQ789F WYAizypENdNJMwQ=; b=SZpsl17NTq2cd4yHE1sx6ZWH/MkTTR/8QnVPLIAGC9Hb FQjcOvL2A/C9KhvCVz2LFOJWaGzpHEc6d3SbLa/KkSuNjAhQsxqCEaa+2ZxsPqQ6 Vj0QHnguhyoUubcKKNH4kvVMbLTodVHWXgQfgQlRikTbXSToXwJPwyZJhD7jUo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=enMJNb 03V1W8+7q/1e4z9XwUZNg8jt7GFeBmVfM8oUqOR1Mmn7Ba2cnBv9NVOyKLYD+IXa BRGmgPHmmvkqmT9Wk47ichzUJJPbjLAFEakY4r9BgJE2/RJKxZ/6h6xhurvkElIp Q8MuyDv/WilaMwXkQ0PB2Ovx+2g8bwYjOCzuY= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 837F683963 for ; Thu, 26 Nov 2009 13:35:26 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 3D60C83962 for ; Thu, 26 Nov 2009 13:35:26 -0500 (EST) Message-ID: <4B0ECAC0.6080609@pobox.com> Date: Thu, 26 Nov 2009 10:36:48 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200911260735.nAQ7ZbYP003893@fs4113.wdf.sap.corp> <4B0EBF04.7090708@jacaranda.org> <4B0EC7F5.5050100@jacaranda.org> In-Reply-To: <4B0EC7F5.5050100@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 7720A2C8-DABA-11DE-B8A3-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:35:33 -0000 David-Sarah Hopwood wrote: > > The TLS spec doesn't seem to be very clear on whether handshake messages > with an unrecognized HandshakeType must cause an error (section 7.4). > Does anyone know what implementations actually do? My code will send a fatal unexpected_message alert. This seems like something that should be a MUST in the spec. Mike From djhopwood@googlemail.com Thu Nov 26 10:39:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171FB3A6A9F for ; Thu, 26 Nov 2009 10:39:37 -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 H9IvpVmMwy-L for ; Thu, 26 Nov 2009 10:39:36 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 139C83A689C for ; Thu, 26 Nov 2009 10:39:35 -0800 (PST) Received: by ewy6 with SMTP id 6so1082220ewy.29 for ; Thu, 26 Nov 2009 10:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=4nRgCpyKOSs2+N3c3dL550WRqrnGhZ4BkQCw2V6zkMc=; b=T4QiTQtiS4uwURNb+kFOsP6XIVmoVti16qytVQ1cswhwBxMK4LrOFZiCWxTUQ0hE+j 7rv0UXx9mO+RsKKTkshyT/48TXFhaAn74chm9ylGjaoKQGrsMlc3XwPaqbwXM6Q4cDBH ws+SkNA/Tphsb/OogiqHDi3G+0/tUMX506Dzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=diYqmRTsE7T+BeEAYbmQae7CP88gd/6ViflPNdwktiOuz4yeCReJ6SC6cvnTJKpQzX LmH9ey7ZI8AmBaoVVvfrWsHwAv7Ajcn6ITqekQZ8eR3rWLYSubmm872YUhoQJNeZzLKz MlN9nK9JrA8jKHoPjuJznsUT+OSzCK1JKxv2U= Received: by 10.213.23.156 with SMTP id r28mr1638456ebb.86.1259260766048; Thu, 26 Nov 2009 10:39:26 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 16sm471583ewy.10.2009.11.26.10.39.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 10:39:24 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0ECB62.2080504@jacaranda.org> Date: Thu, 26 Nov 2009 18:39:30 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0D7A36.5070808@extendedsubset.com> <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> <6b9359640911251153o338f5175m78a20d62e449c7cc@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F3113E31C@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3113E31C@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3AF88F08D00D09ADE503C8CB" Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:39:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3AF88F08D00D09ADE503C8CB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pasi.Eronen@nokia.com wrote: > The current text (in the -00 draft) basically says "identity changes > are OK, but only if the application understands them". >=20 > (And by default, the TLS library must assume the application hasn't > probably thought that something like myConn.getPeerCertificates()=20 > could return a different value each time it's called. Exactly. Unless the TLS library interface uses a callback style where the app has to confirm the new certificate before any data is received/sent on the new session, there's no possible way for the application to get this right. For other kinds of interface, the only secure option is for the library to do a byte-for-byte comparison of the cert. If this breaks some use cases -- tough. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig3AF88F08D00D09ADE503C8CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksOy2kACgkQWUc8YzyzqAfziAD/Znlx3jqdWNMZutmAq1Vzxe3q 7/uYf13t/z6ZBtpz+3kBAJ9rdu1WSX4zO3ivPUxZ93oB1bX043nWJhCXoBY3agk0 =LSu7 -----END PGP SIGNATURE----- --------------enig3AF88F08D00D09ADE503C8CB-- From mrex@sap.com Thu Nov 26 10:53:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB373A6930 for ; Thu, 26 Nov 2009 10:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 37yXjvnYHkQg for ; Thu, 26 Nov 2009 10:53:34 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 61BA53A6801 for ; Thu, 26 Nov 2009 10:53:34 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQIrRm6014370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 19:53:27 +0100 (MET) From: Martin Rex Message-Id: <200911261853.nAQIrRjP018552@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Thu, 26 Nov 2009 19:53:27 +0100 (MET) In-Reply-To: <4B0ECAC0.6080609@pobox.com> from "Michael D'Errico" at Nov 26, 9 10:36:48 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:53:35 -0000 Michael D'Errico wrote: > > David-Sarah Hopwood wrote: > > > > The TLS spec doesn't seem to be very clear on whether handshake messages > > with an unrecognized HandshakeType must cause an error (section 7.4). > > Does anyone know what implementations actually do? > > My code will send a fatal unexpected_message alert. This seems > like something that should be a MUST in the spec. Well. I remember that a few years back when ASN.1 parsers were attacked with random garbage, there was something called "asn1brute.c" that would blindly send a ClientHello directly by a crafted Certificate message and a lot of Servers would choke on the ASN.1 of the certificate, including those who had not even requested a client certificate with CertificateRequest. There may be some unexpected slack in what kind of handshake messages individual TLS implementations might process or even accept in specific situations, where the protocol doesn't define them to be valid. An attitude "the finished message will split the good guys from the bad ones" would not be advisable. -Martin From djhopwood@googlemail.com Thu Nov 26 11:01:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1486F3A6AB8 for ; Thu, 26 Nov 2009 11:01: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 QFp0K8OydJyy for ; Thu, 26 Nov 2009 11:01:33 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 5F7EC3A6801 for ; Thu, 26 Nov 2009 11:01:33 -0800 (PST) Received: by ewy6 with SMTP id 6so1101718ewy.29 for ; Thu, 26 Nov 2009 11:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=s9oEEIb7q+MwV3B9QxjKxHW4Zcrrvm6pZ1OgyVDOM04=; b=JLH/hpFpVQyX4LtsIfPXKcdQWaYyXQiAY+rWOOO71qoSDXl1t23IjhoanSqJSTW6pC IAYyaGe/c6IHprFIkV90a4jwhJYTC8i/2yrOLY4Zrj2Vw/bY9akG9jMC2yiEiEASWt/8 4u/x8is2s6hLray/1QVesKS25OWvZaOf4IKpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=ALWOAYZ/qQ+2t+P6UdOjSKYIUSeXmX+W8T2Als+kWZtS6jGvruLC+VP1DrVQb6xBdQ 1fS/mphgV39vw0gGIbWYT0a1mh+Jh3v1TKI4qXeZUprbBjm4/LchwDmXEeufETaNt+F7 8sPWeD2dqy5o7AAbBafVtvdZFCS91S4d9Xvd0= Received: by 10.213.98.144 with SMTP id q16mr103510ebn.29.1259262086428; Thu, 26 Nov 2009 11:01:26 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 16sm482893ewy.2.2009.11.26.11.01.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 11:01:25 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0ED08C.2000606@jacaranda.org> Date: Thu, 26 Nov 2009 19:01:32 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC014F2796B327C6E14E2A971" Subject: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:01:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC014F2796B327C6E14E2A971 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stefan Santesson wrote: > Consequently, if we design an updated Finished calculation now, we can = keep > that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> T= LS > 1.2. I really don't see any advantage in removing the signalling in TLS 1.3. It doesn't simplify anything. For removing the signalling to work, we would have to specify in the *current* fix that: - sending a client version of {0x03, 0x04} or higher has the same meaning as sending the client->server signal. - negotiating {0x03, 0x04} or higher has the same meaning as sending the server->client signal. That is just additional specification and implementation complexity, and more cases that need to be tested, compared to using the signalling forev= er and treating TLS 1.3+ in exactly the same way as TLS 1.0-1.2. Forget the number of extra bits on the wire (which is negligable); it's the complexi= ty of the spec and of implementations, which necessarily have to support multiple versions, that matters. The original SSLv3 design messed up renegotiation; we'll just have to liv= e with some ugliness as a result of fixing it. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigC014F2796B327C6E14E2A971 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksO0JIACgkQWUc8YzyzqAf1kQD/cGcWbGuJuBJH8gTam62D2XFF nZyZGoa+8t6yc/jjdAgA/1/tlLPVV7SKMmKWWEcM1rBX3JjpK5FWcfw4eNGrH37d =w9JE -----END PGP SIGNATURE----- --------------enigC014F2796B327C6E14E2A971-- From marsh@extendedsubset.com Thu Nov 26 11:07:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACDC3A6A87 for ; Thu, 26 Nov 2009 11:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 PzQn6V5I+D+O for ; Thu, 26 Nov 2009 11:07:16 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id CCF613A68C7 for ; Thu, 26 Nov 2009 11:07:15 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDjgM-0002Xk-73; Thu, 26 Nov 2009 19:07:10 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AB7FC603A; Thu, 26 Nov 2009 19:07:08 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Y8Gfyk600j4tALl9pgVSMGo266G3QhvU= Message-ID: <4B0ED1DA.1070203@extendedsubset.com> Date: Thu, 26 Nov 2009 13:07:06 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dr Stephen Henson References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <4B0EB686.4090905@extendedsubset.com> <4B0EBA86.9010107@drh-consultancy.demon.co.uk> In-Reply-To: <4B0EBA86.9010107@drh-consultancy.demon.co.uk> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Perhaps there's another way. Was: Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:07:16 -0000 Dr Stephen Henson wrote: > Marsh Ray wrote: >> >> At the CCS, instead of replacing the client/server MAC secret data, >> simply XOR-merge the incoming values with the previous ones. >> >> * A one-line software change. >> * Easy even in hardware. >> * Preserves more entropy. >> * No changes to PRF. > > I think this will give problems for external crypto libraries like PKCS#11 where > session key derivation is a mechanism with fixed parameters and the actual keys > are not available in plain text outside the hardware. You'd need to develop a > new mechanism, add it to the PKCS#11 spec and update firmware on every piece of > crypto hardware. PKCS#11 looks like it defines structures for CK_SSL3_KEY_MAT_PARAMS and CK_SSL3_KEY_MAT_OUT (these are also used by TLS). So there are interfaces defined in hardware (or monolithic libraries) that support feeding additional data into the Finished.verify_data calculation but do not allow access to the MAC secrets? *sigh* Why was the Finished data shortened from 36 bytes in SSLv3 to 12 bytes in TLS 1.0 anyway? - Marsh From Chris.Newman@Sun.COM Thu Nov 26 11:18:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6436E3A6AB8 for ; Thu, 26 Nov 2009 11:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, 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 dK8hfShTetMG for ; Thu, 26 Nov 2009 11:18:52 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 516D33A6A8A for ; Thu, 26 Nov 2009 11:18:52 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAQJIj9L018002 for ; Thu, 26 Nov 2009 11:18:45 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTQ00700DHDP100@fe-sfbay-09.sun.com> for tls@ietf.org; Thu, 26 Nov 2009 11:18:45 -0800 (PST) Received: from vpn-129-150-242-97.sfbay.sun.com ([unknown] [71.92.75.71]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTQ00CK7DN6ZX30@fe-sfbay-09.sun.com>; Thu, 26 Nov 2009 11:18:44 -0800 (PST) Date: Thu, 26 Nov 2009 11:18:07 -0800 From: Chris Newman In-reply-to: <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> Sender: Chris.Newman@Sun.COM To: mrex@sap.com Message-id: X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <4B09ECAB.7050205@bolyard.me> <200911230306.nAN365xl020466@fs4113.wdf.sap.corp> <1b587cab0911231411g62437c0fia3e5bcbfcebe8632@mail.gmail.com> Cc: tls@ietf.org Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:18:53 -0000 Actually, the quote is sensible but has been taken out of context and misused widely within the IETF. The "be liberal in what you accept" means accept _all_ valid standards compliant protocol (e.g. things like mandatory-to-ignore extensibility fields). It never meant that implementations should accept incompliant protocol. The "be conservative in what you send out" means to use the minimal subset of the permissible standard syntax to accomplish your goal. For example, the email/http header "Content-Type: text(hi there/hello;)/ plain" is permissible by the standards and semantically equivalent to "Content-Type: text/plain". But a conservative implementation will never generate the former. (As a matter of good protocol design, it's better if the conservative and liberal protocol syntax is as close as possible). So the RI extension is fully compliant with the golden rule, while the alleged extension intolerant server implementations are clear violators of the rule. In my experience, protocols where early implementations reject incompliant protocol aggressively end up with much better real-world interoperability and are much easier to get working by just reading the spec. Protocols where widely deployed early implementations tolerate incompliant implementations end up with systemic interoperability problems that never go away (e.g. SMTP "just send 8-bit with unlabelled charset"), and require a lot of real-world experience beyond the specification in order to produce a production-quality implementation. As a pragmatist, I recognize it is sometimes necessary to accommodate widely deployed broken software, but such accommodation requires supporting data, justification and needs to be as narrowly tailored as possible or the real world drifts away from the standard and overall systemic interoperability gets worse even if that one point-to-point interoperability case is better. - Chris --On November 23, 2009 14:11:56 -0800 Ben Laurie wrote: > On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex wrote: >> It is the golden rule of the IETF >> "be liberal in what you accept, be conservative in what you send out" > > That has proved to be a less-than-great idea, particularly in > protocols where you care about security, which is to say, all of them. From lists@drh-consultancy.demon.co.uk Thu Nov 26 11:24:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46883A6ADC for ; Thu, 26 Nov 2009 11:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 ExadHtRVZhEK for ; Thu, 26 Nov 2009 11:24:58 -0800 (PST) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by core3.amsl.com (Postfix) with ESMTP id BE4C43A6AD2 for ; Thu, 26 Nov 2009 11:24:57 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50193 helo=[192.168.7.8]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10587) with esmtpa (authdaemon_plain:drh) id 1NDjxS-0005zB-DM (Exim 4.69) for tls@ietf.org (return-path ); Thu, 26 Nov 2009 19:24:50 +0000 Message-ID: <4B0ED607.5050003@drh-consultancy.demon.co.uk> Date: Thu, 26 Nov 2009 19:24:55 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <4B0EB686.4090905@extendedsubset.com> <4B0EBA86.9010107@drh-consultancy.demon.co.uk> <4B0ED1DA.1070203@extendedsubset.com> In-Reply-To: <4B0ED1DA.1070203@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Perhaps there's another way. Was: Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:24:59 -0000 Marsh Ray wrote: > Dr Stephen Henson wrote: >> Marsh Ray wrote: >>> At the CCS, instead of replacing the client/server MAC secret data, >>> simply XOR-merge the incoming values with the previous ones. >>> >>> * A one-line software change. >>> * Easy even in hardware. >>> * Preserves more entropy. >>> * No changes to PRF. >> I think this will give problems for external crypto libraries like PKCS#11 where >> session key derivation is a mechanism with fixed parameters and the actual keys >> are not available in plain text outside the hardware. You'd need to develop a >> new mechanism, add it to the PKCS#11 spec and update firmware on every piece of >> crypto hardware. > > PKCS#11 looks like it defines structures for CK_SSL3_KEY_MAT_PARAMS and > CK_SSL3_KEY_MAT_OUT (these are also used by TLS). > Yes, it provides handles to the keys but the keys are not necessarily accessible. Some applications set the parameters so the keys are never extractable for security reasons. Some security standards *require* that keys can never leave the token. That kind of thing causes problems with adding new algorithms (or algorithms with new inputs). Changing the inputs (as opposed to adding new ones) is less likely to cause a problem. Adding new mechanisms or modifying existing ones in incompatible ways is problematical if there is another standards process where it all has to be approved/discussed. If the hardware is FIPS 140-2 validated and needs a new validation to add a new mechanism that's a real pain. As regards PKCS#11 I'm wondering if the use of interfaces like C_DecryptVerify() (which improve throughput by decrypting and MACing in one go) places additional restrictions on what can be done. I'm thinking here if they cause problems with feeding additional data into a handshake which isn't part of the actual handshake and might mess up state with e.g. stream ciphers. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mike-list@pobox.com Thu Nov 26 11:28:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD573A6A9C for ; Thu, 26 Nov 2009 11:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 0WfGWQhpUF2w for ; Thu, 26 Nov 2009 11:28:08 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id C825C3A6859 for ; Thu, 26 Nov 2009 11:28:08 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2411583BD1 for ; Thu, 26 Nov 2009 14:28:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=Op5hpBskUo8HvEGy8f5dp+lX5 fI=; b=EMVFeugABjshqUT8DMknFV3gQaRdfKK32OtHlZuGQmhFJCqtfpdXj9nmI POAS12GUleyWI+aXZIdcXOElrr0jZLXoAnr2jYkGXrQKacT2VYAr0iiT1uz/ydTH 4BhOq+H/IKaV2A64CQDsZDZ89TA4ExDeA/iOoC27ZB51I+SOhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=gfa+U/qdMxoP9zxfXp9 gU176Mnh9piV9DY+VdC0UJD2fFtPpmgULXB4cMpvm4VhBoeHBkGb/fq9vF0fFXQt 6Hu0YpYmENLbp89tX4aNeUteaWWl+DPHlj4SjzeE38yOVwWW/SSuO4f+ak9eRa8I 3Pdtd6/FzTj4Tw3B3PGpsbbk= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1FF8983BD0 for ; Thu, 26 Nov 2009 14:28:03 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C6E4F83BCF for ; Thu, 26 Nov 2009 14:28:02 -0500 (EST) Message-ID: <4B0ED715.20602@pobox.com> Date: Thu, 26 Nov 2009 11:29:25 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D09A5E28-DAC1-11DE-9A2D-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] Alternative to continuing the handshake hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:28:09 -0000 One proposal for solving the renegotiation problem is to just continue the handshake hash from one handshake to the next. This would be a problem for me since my code keeps all of the handshake messages in a list and computes hashes of them at the appropriate times. If we were to continue hashes indefinitely through all renegotiations, I'd have a problem of keeping around an ever-growing list of handshake messages (or I'd have to rewrite my code to keep a running hash). One way to incorporate this idea and be more compatible for my own code would be to seed the handshake message list for a renegotiation with the *hash* of the previous handshake messages. This hash would be placed first in the list before ClientHello. The specification for this would need to make sure to include both Finished messages, even though the last Finished message is currently never included in the hash. Mike From djhopwood@googlemail.com Thu Nov 26 11:37:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0763A6A13 for ; Thu, 26 Nov 2009 11:37:32 -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 iM-0bLOBVGcd for ; Thu, 26 Nov 2009 11:37:31 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 88B7F3A6859 for ; Thu, 26 Nov 2009 11:37:31 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so257671eyf.51 for ; Thu, 26 Nov 2009 11:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=2VQJnJ5XxJRe+ZblyFxZ9g5NbhwOXMzJO/vTkYErxO8=; b=nQtlp4hi4EzGnR3qXfT8K58ZY75A/tzuDchxwzNLxya0NR1z2u1/wsEPW5EGTmp82a uC25s0iLh4esQ8b2I5jvDEKzs/oxKUTB9u4pTjU4gTfWGRn+TWpirBVxW6hlDgUDD818 3zlMw/a8VdEG4ebWNBmGw79tvppwE9AGQ1FPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=SM+Sw8v07f/yAB22JUFa6m69kEtMOM8mPYKl7Jb3+1AXFRxdAR2f/E8/SaXDYaCrQv kJru7LnT7zqIT06G1dyiLSAX2UWLdGguIkmdjG56lmKMorMjvidR4RUVwKTQEDkrn17H OkfdmEfAC9luwpbPYr7rpzGrs6tOxzVkfOkps= Received: by 10.213.25.74 with SMTP id y10mr8672881ebb.14.1259264239548; Thu, 26 Nov 2009 11:37:19 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 14sm501864ewy.7.2009.11.26.11.37.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 11:37:18 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0ED8EB.7030307@jacaranda.org> Date: Thu, 26 Nov 2009 19:37:15 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB34DCD10ED94579538650E36" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:37:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB34DCD10ED94579538650E36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blumenthal, Uri - 0662 - MITLL wrote: > On 11/26/09 11:17 , "Martin Rex" wrote: >> I would really prefer the previous_verify_data to be covered by the >> signature of the ClientVerify message. >=20 > One does not exclude the other, does it? No. Changing both was option 1 in . I think this meets all of the cryptographic requirements; it's just a matter of whether we can find anything simpler. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB34DCD10ED94579538650E36 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksO2PoACgkQWUc8YzyzqAf45AD+OgwjsM3DCVr6jMWXnRvIO3M0 hqPHmYM4ew7WiYSw7o4BAKEVks8QJVE6MIkSh4kjpkkgCulAUVrE7i1jpmSP3Phn =RtIX -----END PGP SIGNATURE----- --------------enigB34DCD10ED94579538650E36-- From uri@ll.mit.edu Thu Nov 26 11:45:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FAB3A6ACF for ; Thu, 26 Nov 2009 11:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQkJPDG2igpe for ; Thu, 26 Nov 2009 11:45:37 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 30E2D3A6814 for ; Thu, 26 Nov 2009 11:45:36 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAQJjUY6027339; Thu, 26 Nov 2009 14:45:30 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAh8aqj0; Thu Nov 26 14:43:42 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Thu, 26 Nov 2009 14:43:42 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: David-Sarah Hopwood , "tls@ietf.org" Date: Thu, 26 Nov 2009 14:43:40 -0500 Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: Acpuz+WPG+z02x7ATmyRqYxL6z/DeQAANs1X Message-ID: In-Reply-To: <4B0ED8EB.7030307@jacaranda.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:45:38 -0000 On 11/26/09 14:37 , "David-Sarah Hopwood" wrote: > Blumenthal, Uri - 0662 - MITLL wrote: >> On 11/26/09 11:17 , "Martin Rex" wrote: >>> I would really prefer the previous_verify_data to be covered by the >>> signature of the ClientVerify message. >>=20 >> One does not exclude the other, does it? >=20 > No. Changing both was option 1 in > . > I think this meets all of the cryptographic requirements; it's just > a matter of whether we can find anything simpler. Probably no we can't. And it's about time we stopped arguing and started solidifying the solution= . :-)=20 --=20 Regards, Uri From djhopwood@googlemail.com Thu Nov 26 11:53:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B683A6816 for ; Thu, 26 Nov 2009 11:53:25 -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 YOUuKQcE3dm2 for ; Thu, 26 Nov 2009 11:53:24 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 4776D3A67A2 for ; Thu, 26 Nov 2009 11:53:24 -0800 (PST) Received: by ewy7 with SMTP id 7so1163502ewy.28 for ; Thu, 26 Nov 2009 11:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=qzCyfvQ9LfGDCTeSab0KuE9LRD138dV+g//noPojBcw=; b=p0/2cBM1K8bu+27/Eh1gvQ74gX/KzDJAsefGvwGv7DxxvGhLDAmJvnRVNxL9iMrMSq APvSQ8oUw2rcqft1PqIURJ63Br2yd98MzDZzpDznEuCDgtkIlsn95qh/LrKHUtM8fXWK SsqZH5pavzCewZdL4QJFL4qPrwvgtbJUiakag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=bZ2D4DaCuyAzI5i/xFsCbYFpPMtWEAxbECGBsbV1GDK9hIiRy5xz1h6bvGgWNNvTm5 xV0N6g1TIAzyF357lCf2FNvRR+be8+wl9uVPd4x13GR5jWyXNxGcpg7jNG02fj1cXqHJ AA1VAN0OQh/XyjEuj9NOVhvnFf3X+invK00z0= Received: by 10.213.45.144 with SMTP id e16mr116737ebf.99.1259265192191; Thu, 26 Nov 2009 11:53:12 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 14sm511008ewy.7.2009.11.26.11.53.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 11:53:11 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B0EDCAB.60908@jacaranda.org> Date: Thu, 26 Nov 2009 19:53:15 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <4B0DBB97.5050500@pobox.com> <4B0DFB03.5020201@pobox.com> <4B0E1501.5080002@jacaranda.org> <4B0EADC6.4070306@extendedsubset.com> In-Reply-To: <4B0EADC6.4070306@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig41CC9B8C8B4B4847582C071F" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:53:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig41CC9B8C8B4B4847582C071F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > David-Sarah Hopwood wrote: >> Michael D'Errico wrote: >>>> Eric Rescorla wrote: >>>> >>>>>> 3) Incorporate previous verify_data into Finished calc. >>>>> I'm not happy with this, actually. >>> Would this work: >>> >>> Finished =3D verify_data XOR previous_verify_data >> >> No. The previous_verify_data has to be in the input to the PRF >> that also depends on the master_secret. If you just XOR it to >> the output, then the attacker doesn't need to know the master_secret >> in order to change the unmodified Finished to the modified one. >=20 > If I understand it correctly, Mitm could decrypt the renegotiated > Finished message record, modify it, and re-encrypt it. > Effectively this means the authentication and integrity guarantees on > protocol could be no stronger than the encryption. That could be a > significant weakening of the protocol's security. The Finished messages are both encrypted and MAC'd, so to be more precise= , it would be dependent on the non-malleability of this authenticated encryption. There is some redundancy in the SSL/TLS handshake design here= ; it would be secure even if the Finished messages had not been encrypted and MAC'd, for example. But there is no good reason to eliminate any part= of that redundancy. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig41CC9B8C8B4B4847582C071F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksO3LQACgkQWUc8YzyzqAcFdQD/coEx4l3sbVTZiAoHomOmkVXC N2iYIOa72UupT3vNCqUBAI9hAS8javz6FWqS9EvJnh07i+b173ZJ7wIsBvqVRhf4 =Dw+c -----END PGP SIGNATURE----- --------------enig41CC9B8C8B4B4847582C071F-- From marsh@extendedsubset.com Thu Nov 26 11:57:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09EB43A68AF for ; Thu, 26 Nov 2009 11:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 OkpLPeD3ngAR for ; Thu, 26 Nov 2009 11:57:10 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 4BACB3A67CF for ; Thu, 26 Nov 2009 11:57:10 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDkSe-000BAm-Lr; Thu, 26 Nov 2009 19:57:04 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5F18F603A; Thu, 26 Nov 2009 19:57:03 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19HEC45w7t0HO9dJ+XEOrX5dsFOUOk69IU= Message-ID: <4B0EDD8D.2030501@extendedsubset.com> Date: Thu, 26 Nov 2009 13:57:01 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David-Sarah Hopwood References: <4B0D7A36.5070808@extendedsubset.com> <200911251852.nAPIqA2a014276@fs4113.wdf.sap.corp> <6b9359640911251153o338f5175m78a20d62e449c7cc@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F3113E31C@NOK-EUMSG-01.mgdnok.nokia.com> <4B0ECB62.2080504@jacaranda.org> In-Reply-To: <4B0ECB62.2080504@jacaranda.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:57:11 -0000 David-Sarah Hopwood wrote: > Pasi.Eronen@nokia.com wrote: >> The current text (in the -00 draft) basically says "identity changes >> are OK, but only if the application understands them". >> >> (And by default, the TLS library must assume the application hasn't >> probably thought that something like myConn.getPeerCertificates() >> could return a different value each time it's called. > > Exactly. Unless the TLS library interface uses a callback style > where the app has to confirm the new certificate before any data > is received/sent on the new session, All the ones that I've looked at provide exactly that, though it's not perfect either. > there's no possible way for > the application to get this right. And I have yet to see any developer-oriented documentation provide example code that does everything right. > For other kinds of interface, > the only secure option is for the library to do a byte-for-byte > comparison of the cert. A simpler alternative is to RECOMMEND that library implementations default to disallowing renegotiation but allow a config option if the app wants to enable it (perhaps requiring a callback be overridden). The return value of the callback should be able to immediately terminate the handshake and discard buffered data on failure. > If this breaks some use cases -- tough. Easy for you to say, easy for others to ignore. - Marsh From stephen.farrell@cs.tcd.ie Thu Nov 26 12:03:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2A33A6AC7 for ; Thu, 26 Nov 2009 12:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-1.529, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1, SARE_OBFU_ALL=0.751] 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 ZKkZg0N-YmGE for ; Thu, 26 Nov 2009 12:03:57 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id E0E1D3A6AE1 for ; Thu, 26 Nov 2009 12:03:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 4EC1C1003F574; Thu, 26 Nov 2009 20:03:49 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo676Q7oaFbR; Thu, 26 Nov 2009 20:03:46 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 867101003F528; Thu, 26 Nov 2009 20:03:46 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 61AA37C12D; Thu, 26 Nov 2009 20:03:46 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8QS8i+eD1+f; Thu, 26 Nov 2009 20:03:41 +0000 (GMT) Received: from [10.87.48.4] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail01.newbay.com (Postfix) with ESMTP id 87D5D7C124; Thu, 26 Nov 2009 20:03:41 +0000 (GMT) References: Message-Id: <521B99C2-7A2B-4A6C-BFB4-C8CA960C6E1B@cs.tcd.ie> From: Stephen Farrell To: "Blumenthal, Uri - 0662 - MITLL" In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Date: Thu, 26 Nov 2009 20:03:35 +0000 Cc: "tls@ietf.org" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:03:57 -0000 On 26 Nov 2009, at 19:43, "Blumenthal, Uri - 0662 - MITLL" wrote: > > > And it's about time we stopped arguing and started solidifying the > solution. > :-) +1 S. From mrex@sap.com Thu Nov 26 12:15:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729013A6ADD for ; Thu, 26 Nov 2009 12:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 nNkZpe4pioI9 for ; Thu, 26 Nov 2009 12:15:40 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2C0393A6859 for ; Thu, 26 Nov 2009 12:15:39 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQKFVk5029941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 21:15:31 +0100 (MET) From: Martin Rex Message-Id: <200911262015.nAQKFUWH023724@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 26 Nov 2009 21:15:30 +0100 (MET) In-Reply-To: <4B0EDD8D.2030501@extendedsubset.com> from "Marsh Ray" at Nov 26, 9 01:57:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:15:42 -0000 Marsh Ray wrote: > > David-Sarah Hopwood wrote: > > Pasi.Eronen@nokia.com wrote: > >> The current text (in the -00 draft) basically says "identity changes > >> are OK, but only if the application understands them". > >> > >> (And by default, the TLS library must assume the application hasn't > >> probably thought that something like myConn.getPeerCertificates() > >> could return a different value each time it's called. > > > > Exactly. Unless the TLS library interface uses a callback style > > where the app has to confirm the new certificate before any data > > is received/sent on the new session, > > All the ones that I've looked at provide exactly that, though it's not > perfect either. OpenSSL offers a callback, but an app is _not_ required to register a callback. It can easily use SSL_get_peer_certificate() or SSL_get_peer_cert_chain(). after SSL_connect() completes successfully. > > > there's no possible way for > > the application to get this right. > > And I have yet to see any developer-oriented documentation provide > example code that does everything right. It's worse than that. There has been no possible way for a TLS implementation to get this right! When would be the correct time to fire such a callback? Try to describe it in terms of before/while/after which Handshake message any why. -Martin From stefan@aaa-sec.com Thu Nov 26 12:36:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596583A6A70 for ; Thu, 26 Nov 2009 12:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wURu+AIFfYrf for ; Thu, 26 Nov 2009 12:36:31 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 76B323A6934 for ; Thu, 26 Nov 2009 12:36:30 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A0507293761 for ; Thu, 26 Nov 2009 21:36:31 +0100 (CET) Received: (qmail 53250 invoked from network); 26 Nov 2009 20:36:23 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Nov 2009 20:36:23 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 26 Nov 2009 21:36:22 +0100 From: Stefan Santesson To: David-Sarah Hopwood , Message-ID: Thread-Topic: [TLS] What would be the point of removing signalling in TLS 1.3? Thread-Index: Acpu2B15KdRChGpomUyrYbWaJCaR3w== In-Reply-To: <4B0ED08C.2000606@jacaranda.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:36:32 -0000 If you fix the Finished message calculation, making it immune to the renegotiation attack, and making it the standard Finished calculation for 1.3.... Then why would you need to signal that you are using the standard Finished calculation? /Stefan On 09-11-26 8:01 PM, "David-Sarah Hopwood" wrote: > Stefan Santesson wrote: >> Consequently, if we design an updated Finished calculation now, we can keep >> that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS >> 1.2. > > I really don't see any advantage in removing the signalling in TLS 1.3. > It doesn't simplify anything. > > For removing the signalling to work, we would have to specify in the > *current* fix that: > > - sending a client version of {0x03, 0x04} or higher has the same > meaning as sending the client->server signal. > > - negotiating {0x03, 0x04} or higher has the same meaning as sending > the server->client signal. > > That is just additional specification and implementation complexity, and > more cases that need to be tested, compared to using the signalling forever > and treating TLS 1.3+ in exactly the same way as TLS 1.0-1.2. Forget the > number of extra bits on the wire (which is negligable); it's the complexity > of the spec and of implementations, which necessarily have to support > multiple versions, that matters. > > The original SSLv3 design messed up renegotiation; we'll just have to live > with some ugliness as a result of fixing it. From SRS0=RRgI=HO=acm.org=bmoeller@srs.kundenserver.de Thu Nov 26 12:27:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A481D3A6914 for ; Thu, 26 Nov 2009 12:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 c2RLvyLHGIko for ; Thu, 26 Nov 2009 12:27:09 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id A1A103A6861 for ; Thu, 26 Nov 2009 12:27:08 -0800 (PST) Received: from bmoeller-macbookpro.fritz.box (77-57-208-242.dclient.hispeed.ch [77.57.208.242]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MIRvH-1NABlF2IBj-0043Y4; Thu, 26 Nov 2009 21:26:59 +0100 From: Bodo Moeller To: Dr Stephen Henson In-Reply-To: <4B082B08.3020406@drh-consultancy.demon.co.uk> References: <4B082B08.3020406@drh-consultancy.demon.co.uk> Message-Id: <138B92E3-A450-4C99-B5C1-1C9253864BE3@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Nov 2009 21:26:57 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX181wK8akvCYEjTf+k8ZrRa0hZzV93PNyAHkBNt t03gCR63R3Zl9bA8jaVDw2BfwpSnRFLJEsX+W2jlYQ9H7vrz06 6tNEza+KgtbXkMJ/WZP/A== Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:38:22 -0000 On Nov 21, 2009, at 7:01 PM, Dr Stephen Henson wrote: > Joseph Salowey (jsalowey) wrote: >> To try to keep this concrete, please respond with answers to this >> question: >> >> Support for the draft: >> - I support this draft >> - I support this draft with the following modification >> - I would support an entirely different proposal (please identify >> it; be >> specific) >> >> If you are proposing a modification, in addition to providing a >> description and rationale for a modification to the document it is >> helpful to provide sample text of the modification. Also, please >> indicate whether you would only support the draft with your >> modification >> or whether you can live with it unmodified. > Firstly does this mean the 00 draft or the 01 one? This was about draft-ietf-tls-renegotiation-00.txt, which succeeded draft-rescorla-tls-renegotiation-01.txt (and has now been succeeded by draft-ietf-tls-renegotiation-01.txt). See http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 for the complete history. Bodo From marsh@extendedsubset.com Thu Nov 26 12:53:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE00E3A6359 for ; Thu, 26 Nov 2009 12:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 d1FVAzCYMV70 for ; Thu, 26 Nov 2009 12:53:59 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id E956D3A67E9 for ; Thu, 26 Nov 2009 12:53:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDlLd-0001p8-9X; Thu, 26 Nov 2009 20:53:53 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C56B7603A; Thu, 26 Nov 2009 20:53:50 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18IedPbPP5EsScQULA5sIpOdqDNsX/vmVk= Message-ID: <4B0EEADC.7030709@extendedsubset.com> Date: Thu, 26 Nov 2009 14:53:48 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200911262015.nAQKFUWH023724@fs4113.wdf.sap.corp> In-Reply-To: <200911262015.nAQKFUWH023724@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:53:59 -0000 Martin Rex wrote: > Marsh Ray wrote: > >> And I have yet to see any developer-oriented documentation provide >> example code that does everything right. > > It's worse than that. There has been no possible way for > a TLS implementation to get this right! In the liberal spec-interpretation general case, yes. > When would be the correct time to fire such a callback? 1. Many applications could run with a default of disabling renegotiation entirely. You could possibly live without a callback in many of those cases. 2. The implementation could refuse data between hello and finished and provide callbacks on cert verify and finished. 3. Otherwise, a callback on just about every handshake message would be needed, and the subtleties of application data, alerts, and handshake messages would all be pushed off onto the application. > Try to describe it in terms of before/while/after which Handshake > message any why. 1. Disable all renegotiation. or 2. Consult your application-level protocol documentation which will perfectly spell out the allowed sequence of TLS messages. :-) - Marsh From marsh@extendedsubset.com Thu Nov 26 13:23:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A9A3A6AE7 for ; Thu, 26 Nov 2009 13:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Iwt3bubC3Ngg for ; Thu, 26 Nov 2009 13:23:01 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id F19143A6A5B for ; Thu, 26 Nov 2009 13:23:00 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NDlnj-000El9-Aj; Thu, 26 Nov 2009 21:22:55 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 071DD603A; Thu, 26 Nov 2009 21:22:54 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/485y7gGry+bEd2Pk1SHZU6qZ7ANsgUkU= Message-ID: <4B0EF1AB.8050506@extendedsubset.com> Date: Thu, 26 Nov 2009 15:22:51 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stefan Santesson , "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 21:23:01 -0000 Stefan Santesson wrote: > If you fix the Finished message calculation, making it immune to the > renegotiation attack, and making it the standard Finished calculation for > 1.3.... Then why would you need to signal that you are using the standard > Finished calculation? So that clients and servers can be upgraded over a period of time without causing interoperability problems. - Marsh From SRS0=RRgI=HO=acm.org=bmoeller@srs.kundenserver.de Thu Nov 26 14:07:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304333A6947 for ; Thu, 26 Nov 2009 14:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 L6fYDY7yp8fp for ; Thu, 26 Nov 2009 14:07:41 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 36E843A689E for ; Thu, 26 Nov 2009 14:07:41 -0800 (PST) Received: from bmoeller-macbookpro.fritz.box (77-57-208-242.dclient.hispeed.ch [77.57.208.242]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LfWft-1Ny3bh46BN-00p3c6; Thu, 26 Nov 2009 23:07:34 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4B0EF1AB.8050506@extendedsubset.com> References: <4B0EF1AB.8050506@extendedsubset.com> Message-Id: <6A2B0911-C59D-4A11-94FA-713E46E89488@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Nov 2009 23:07:32 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1/pA8jcZZSibM775wLGuk1pYUK5VcnUPi3bBmS R3UJvdor0i4soUXF1KteWUT8jF4jMLW2A5yGBj8qOH5fGw0Ktc 19l7DHdrQ69jijvmob3gg== Cc: "tls@ietf.org" Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 22:07:42 -0000 On Nov 26, 2009, at 10:22 PM, Marsh Ray wrote: > Stefan Santesson wrote: >> If you fix the Finished message calculation, making it immune to the >> renegotiation attack, and making it the standard Finished >> calculation for >> 1.3.... Then why would you need to signal that you are using the >> standard >> Finished calculation? > > So that clients and servers can be upgraded over a period of time > without causing interoperability problems. There are more than two ways how to treat signaling (how to signal that a new Finished computation should be used) with respect to future protocol versions, i.e., TLS 1.3 and later: - The specifications could mandate keeping the explicit signal even with TLS 1.3+. - The specifications could require an explicit signal only for those TLS 1.3+ implementations that do offer backwards compatibility with earlier protocol versions (i.e., if the *negotiated* protocol version is TLS 1.3 or later, that would imply that the new Finished computation should be used). - The specifications could require an explicit signal only for implementations that don't announce TLS 1.3+ (i.e., if the *requested* protocol version is TLS 1.3+, that would imply that the new Finished computation should be used). Stefan's proposal in the original message, it seems, was the third variant. David's comment suggested that because of the complexity that comes with that variant, we should stick to the first one (and always keep signaling). That's not implied, though. The second variant makes a lot of sense to me -- it's just not something that the current specification would or should have to say a final word on: that's best left to the TLS 1.3 specification. Bodo From ynir@checkpoint.com Thu Nov 26 14:39:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37E63A6B19 for ; Thu, 26 Nov 2009 14:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, SARE_OBFU_ALL=0.751] 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 K8+18UGwL3Mn for ; Thu, 26 Nov 2009 14:39:04 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A17EE3A6B13 for ; Thu, 26 Nov 2009 14:39:03 -0800 (PST) X-CheckPoint: {4B0EFFB7-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9A57D29C008; Fri, 27 Nov 2009 00:38:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 70F5A29C002; Fri, 27 Nov 2009 00:38:56 +0200 (IST) X-CheckPoint: {4B0EFFB6-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAQMctGo010673; Fri, 27 Nov 2009 00:38:56 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 27 Nov 2009 00:39:01 +0200 From: Yoav Nir To: "Blumenthal, Uri - 0662 - MITLL" Date: Fri, 27 Nov 2009 00:38:51 +0200 Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: Acpu6T/MK5UJCyFuQrCECzXomLVfRQ== Message-ID: <32C4392B-749C-47D7-B625-C769A18DE9DE@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 22:39:04 -0000 On Nov 26, 2009, at 8:11 PM, Blumenthal, Uri - 0662 - MITLL wrote: > I forgot about that. Good point. I agree. >=20 > As for SSLv3 - SMNP (Simply Not My Problem :). Would be nice to address i= t > as well, but I'd rather not bend over backwards to also fix SSLv3. >=20 > On 11/26/09 12:23 , "David-Sarah Hopwood" > wrote: >> Blumenthal, Uri - 0662 - MITLL wrote: >>> Yes, previous_verify_data MUST be a part of the input to the PRF. What = Yoav >>> Nir said (XOR-ing it with the master_secret), should work (out of hand = - >>> anybody sees a problem with it?). >>=20 >> The previous_verify_data is not necessarily secret, so this requires the >> PRF to be secure against related-key attack. The particular PRFs used in >> SSLv3 and TLS 1.0 to 1.2 should be secure in that sense, but (if we >> decide to use this approach) I still prefer what I suggested before: >>=20 >> verify_data =3D >> PRF(master_secret, finished_label, Hash(handshake_messages) >> + previous_verify_data) >> [0..verify_data_length-1]; >>=20 >> which uses the PRF in a more conventional way. > --=20 > Regards, > Uri uri@ll.mit.edu I don't see why my suggestion doesn't hold for SSLv3 as well. Here's from t= he spec: enum { client(0x434C4E54), server(0x53525652) } Sender; struct { opaque md5_hash[16]; opaque sha_hash[20]; } Finished; md5_hash MD5(master_secret + pad2 + MD5(handshake_messages + Sender + master_secret + pad1)); sha_hash SHA(master_secret + pad2 + SHA(handshake_messages + Sender + master_secret + pad1)); So this could be changed in renegotiation to the following, or the Sender f= ield could be replaced with the contents of the previous Finished message (= it's like the finished label) enum { client(0x434C4E54), server(0x53525652) } Sender; struct { opaque md5_hash[16]; opaque sha_hash[20]; } Finished; md5_hash MD5(master_secret^previous_Finished_message + pad2 + MD5(handshake_= messages + Sender + master_secret + pad1)); sha_hash SHA(master_secret^previous_Finished_message + pad2 + SHA(handshake_= messages + Sender + master_secret + pad1)); From uri@ll.mit.edu Thu Nov 26 15:51:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9A03A6974 for ; Thu, 26 Nov 2009 15:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEbkygim912q for ; Thu, 26 Nov 2009 15:51:18 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 64D883A6774 for ; Thu, 26 Nov 2009 15:51:18 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nAQNpCXV011428 for ; Thu, 26 Nov 2009 18:51:12 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAKma4Tv; Thu Nov 26 18:49:57 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 26 Nov 2009 18:49:57 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Thu, 26 Nov 2009 18:49:57 -0500 Thread-Topic: [TLS] What would be the point of removing signalling in TLS 1.3? Thread-Index: Acpu3qbA8WecvWouRcOD70Cq0aNvtAAFIIXn Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F45@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 23:51:19 -0000 SSdtIG5vdCBzdXJlIGl0J3MgYSBnb29kIGVub3VnaCByZWFzb24uDQoNCg0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2Vz QGlldGYub3JnPg0KVG86IFN0ZWZhbiBTYW50ZXNzb24gPHN0ZWZhbkBhYWEtc2VjLmNvbT47IHRs c0BpZXRmLm9yZyA8dGxzQGlldGYub3JnPg0KU2VudDogVGh1IE5vdiAyNiAxNjoyMjo1MSAyMDA5 ClN1YmplY3Q6IFJlOiBbVExTXSBXaGF0IHdvdWxkIGJlIHRoZSBwb2ludCBvZiByZW1vdmluZyBz aWduYWxsaW5nIGluIFRMUyAxLjM/DQoNClN0ZWZhbiBTYW50ZXNzb24gd3JvdGU6DQo+IElmIHlv dSBmaXggdGhlIEZpbmlzaGVkIG1lc3NhZ2UgY2FsY3VsYXRpb24sIG1ha2luZyBpdCBpbW11bmUg dG8gdGhlDQo+IHJlbmVnb3RpYXRpb24gYXR0YWNrLCBhbmQgbWFraW5nIGl0IHRoZSBzdGFuZGFy ZCBGaW5pc2hlZCBjYWxjdWxhdGlvbiBmb3INCj4gMS4zLi4uLiBUaGVuIHdoeSB3b3VsZCB5b3Ug bmVlZCB0byBzaWduYWwgdGhhdCB5b3UgYXJlIHVzaW5nIHRoZSBzdGFuZGFyZA0KPiBGaW5pc2hl ZCBjYWxjdWxhdGlvbj8NCg0KU28gdGhhdCBjbGllbnRzIGFuZCBzZXJ2ZXJzIGNhbiBiZSB1cGdy YWRlZCBvdmVyIGEgcGVyaW9kIG9mIHRpbWUNCndpdGhvdXQgY2F1c2luZyBpbnRlcm9wZXJhYmls aXR5IHByb2JsZW1zLg0KDQotIE1hcnNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From nelson@bolyard.me Thu Nov 26 19:53:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688593A67EE for ; Thu, 26 Nov 2009 19:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 XYwVO46UmVDC for ; Thu, 26 Nov 2009 19:53:06 -0800 (PST) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id 77B2E3A63D3 for ; Thu, 26 Nov 2009 19:53:05 -0800 (PST) Received: (qmail 1017 invoked from network); 27 Nov 2009 03:52:56 -0000 Received: from unknown (24.5.142.42) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 27 Nov 2009 03:52:56 -0000 Message-ID: <4B0F4D98.7040909@bolyard.me> Date: Thu, 26 Nov 2009 19:55:04 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911210002.nAL02CEx007574@fs4113.wdf.sap.corp> <8D2529C4D76F7E4B2AC769A4@446E7922C82D299DB29D899F> In-Reply-To: <8D2529C4D76F7E4B2AC769A4@446E7922C82D299DB29D899F> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 03:53:07 -0000 On 2009-11-26 09:43 PST, Chris Newman wrote: > This would solve the problem of SSLv3-only implementations that must be > upgraded to address this issue being difficult to upgrade to full TLS with > general extensions support. That's a problem I believe may be worth > solving for this particular security vulnerability. > > It also addresses the very real problem that having two ways to negotiate > the same thing is bad design and there have been proposals to negotiate via > different protocol elements in SSLv3 than in TLS. > The alleged extensions-intolerant servers were broken when they were first > released and it is unfortunate their failure to comply with standards was > not identified and fixed sooner. Since they must be upgraded to either be > made secure or identified as secure, why not fix the standards-compliance > bug (failure to tolerate extensions) at the same time? Seems a lot cleaner > and safer than kludging crap into critical fields in the ServerHello. I categorically agree with the above statements. Who is to say that this is the last serious vulnerability that will be found in SSL 3.[0123]? When the next one is found, will we again be urged to steal more bits in existing SSL 3.0 message fields? Marsh Ray made the excellent point that SSL 3.0 was (in some sense) doomed from the start by the lack of any extensibility feature that allowed flaws like this to be addressed without changing the base protocol. EKR's RI proposal clearly demonstrates the capability of TLS's extension facility to be used to cleanly and simply fix problems like this WITHOUT needing to make ANY changes to the base protocol at all (not needing to incorporate phantom messages into the handshake hashes). As keepers of the public's trust to specify standards for transport layer security, it behooves us to evolve the protocol in ways that look forward to the possibility of another vulnerability being found in the base protocol, and not be forced to rely on yet another hack to all existing versions of the base protocol, and yet another encroachment on the version number space, to fix it. > So this is a problem that I do not consider worth solving -- indeed I > prefer solutions that break implementations that already demonstrated an > inability to follow published standards. As a pragmatist, I'd consider an > exception if a particular implementation was widely deployed and difficult > to upgrade, but we'd need to see a list of these non-compliant servers to > make that evaluation. If nobody is motivated enough to produce that list, > I assume none of them are problematic. I agree. Let's see some evidence, beyond the mere fact that the browser developers have not found it urgent to remove their SSL fall-back code 11 years after they put it in, that the Internet and its users really depend on those non-standard servers before we agree to forever codify the nonstandard behavior of those servers in a new RFC. From nelson@bolyard.me Thu Nov 26 20:38:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BECAE3A67BD for ; Thu, 26 Nov 2009 20:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 vutW3d3DAMot for ; Thu, 26 Nov 2009 20:38:58 -0800 (PST) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id DCE033A67A3 for ; Thu, 26 Nov 2009 20:38:58 -0800 (PST) Received: (qmail 7861 invoked from network); 27 Nov 2009 04:38:51 -0000 Received: from unknown (24.5.142.42) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 27 Nov 2009 04:38:51 -0000 Message-ID: <4B0F585B.9090500@bolyard.me> Date: Thu, 26 Nov 2009 20:40:59 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200911262015.nAQKFUWH023724@fs4113.wdf.sap.corp> In-Reply-To: <200911262015.nAQKFUWH023724@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 04:38:59 -0000 On 2009-11-26 12:15 PST, Martin Rex wrote: > Marsh Ray wrote: >> David-Sarah Hopwood wrote: >>> Pasi.Eronen@nokia.com wrote: >>>> The current text (in the -00 draft) basically says "identity changes >>>> are OK, but only if the application understands them". >>>> >>>> (And by default, the TLS library must assume the application hasn't >>>> probably thought that something like myConn.getPeerCertificates() >>>> could return a different value each time it's called. >>> >>> Exactly. Unless the TLS library interface uses a callback style >>> where the app has to confirm the new certificate before any data >>> is received/sent on the new session, >> >> All the ones that I've looked at provide exactly that, NSS certainly does, also. >> though it's not perfect either. > > OpenSSL offers a callback, but an app is _not_ required to > register a callback. It can easily use > SSL_get_peer_certificate() or SSL_get_peer_cert_chain(). > after SSL_connect() completes successfully. NSS provides a callback. If the app does not register its own callback function, then NSS provides its own default callback which verifies the cert chain against the user's preconfigured set of trust anchors, doing OCSP checking (if configured to do so), then finally checking that the cert bears a DNS name or pattern that matches the name previously registered by the application. Whether the callback is the default one or an application supplied one, if it returns a failure result, that is fatal to that handshake. The handshake will not complete, and no application data will ever travel on the session that would have been established if that handshake had completed. >>> there's no possible way for the application to get this right. >> And I have yet to see any developer-oriented documentation provide >> example code that does everything right. With NSS, the only way for an application to get it wrong is to deliberately return a false success response to the callback without checking the cert. Sadly, I have seen apps do just that. :( From nelson@bolyard.me Thu Nov 26 20:50:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E515D3A6891 for ; Thu, 26 Nov 2009 20:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 Pj4+9o9SHcML for ; Thu, 26 Nov 2009 20:50:10 -0800 (PST) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id 224BA3A6897 for ; Thu, 26 Nov 2009 20:50:10 -0800 (PST) Received: (qmail 14662 invoked from network); 27 Nov 2009 04:50:04 -0000 Received: from unknown (24.5.142.42) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 27 Nov 2009 04:50:04 -0000 Message-ID: <4B0F5AFC.3020600@bolyard.me> Date: Thu, 26 Nov 2009 20:52:12 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: "tls@ietf.org" References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <4B0EB686.4090905@extendedsubset.com> <4B0EBA86.9010107@drh-consultancy.demon.co.uk> <4B0ED1DA.1070203@extendedsubset.com> <4B0ED607.5050003@drh-consultancy.demon.co.uk> In-Reply-To: <4B0ED607.5050003@drh-consultancy.demon.co.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Perhaps there's another way. Was: Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 04:50:11 -0000 On 2009-11-26 11:24 PST, Dr Stephen Henson wrote: > Yes, it provides handles to the keys but the keys are not necessarily > accessible. Some applications set the parameters so the keys are never > extractable for security reasons. Some security standards *require* that > keys can never leave the token. > > That kind of thing causes problems with adding new algorithms (or > algorithms with new inputs). Changing the inputs (as opposed to adding > new ones) is less likely to cause a problem. > > Adding new mechanisms or modifying existing ones in incompatible ways is > problematical if there is another standards process where it all has to > be approved/discussed. If the hardware is FIPS 140-2 validated and needs > a new validation to add a new mechanism that's a real pain. > > As regards PKCS#11 I'm wondering if the use of interfaces like > C_DecryptVerify() (which improve throughput by decrypting and MACing in > one go) places additional restrictions on what can be done. I'm thinking > here if they cause problems with feeding additional data into a handshake > which isn't part of the actual handshake and might mess up state with > e.g. stream ciphers. > > Steve. Yes, this is a very grave concern. PLEASE do not propose any changes that would necessitate new PKCS#11 mechanisms, which, in turn, would necessitate new FIPS 140-2 or 140-3(!) security evaluations and certifications. That would slow the deployment of a new fix in certain (governmental) environments by YEARS (no kidding). From nelson@bolyard.me Thu Nov 26 21:04:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3F53A67EB for ; Thu, 26 Nov 2009 21:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 ICrZ1nnHMUTo for ; Thu, 26 Nov 2009 21:04:57 -0800 (PST) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id 2EBE53A67A3 for ; Thu, 26 Nov 2009 21:04:56 -0800 (PST) Received: (qmail 13075 invoked from network); 27 Nov 2009 05:04:46 -0000 Received: from unknown (24.5.142.42) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 27 Nov 2009 05:04:46 -0000 Message-ID: <4B0F5E6D.2050904@bolyard.me> Date: Thu, 26 Nov 2009 21:06:53 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: "tls@ietf.org" References: <4B0EF1AB.8050506@extendedsubset.com> In-Reply-To: <4B0EF1AB.8050506@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 05:04:58 -0000 On 2009-11-26 13:22 PST, Marsh Ray wrote: > Stefan Santesson wrote: >> If you fix the Finished message calculation, making it immune to the >> renegotiation attack, and making it the standard Finished calculation for >> 1.3.... Then why would you need to signal that you are using the standard >> Finished calculation? > > So that clients and servers can be upgraded over a period of time > without causing interoperability problems. But clients and servers that are written to speak 1.3 (which doesn't exist today) would be written to do the right thing from day 1, when they negotiate version 1.3. There would be no "upgrade over a period of time" for clients and servers that negotiation version 1.3. I'd propose the use of RI in 1.3 this way. A 1.3 client that also implements lesser versions MUST send RI in the client hello, in case the server does not implement 1.3, but implements some lesser version. A 1.3 server that also implements lesser versions MUST send RI in the server hello when the client hello asks for a version less than 1.3 and the server hello agrees to negotiate a version less than 1.3. A 1.3 server that receives a client hello bearing version 1.3 (or greater) NEVER returns RI in the server hello when the server hello negotiates version 1.3 (or greater). From nelson@bolyard.me Thu Nov 26 21:19:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385A33A6874 for ; Thu, 26 Nov 2009 21:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 9uQb+HeZAbxq for ; Thu, 26 Nov 2009 21:19:10 -0800 (PST) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 478CE3A63D3 for ; Thu, 26 Nov 2009 21:19:10 -0800 (PST) Received: (qmail 32180 invoked from network); 27 Nov 2009 05:19:04 -0000 Received: from unknown (24.5.142.42) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 27 Nov 2009 05:19:04 -0000 Message-ID: <4B0F61C7.2070804@bolyard.me> Date: Thu, 26 Nov 2009 21:21:11 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: "Blumenthal, Uri - 0662 - MITLL" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 05:19:11 -0000 On 2009-11-26 08:04 PST, Blumenthal, Uri - 0662 - MITLL wrote: > Yes, previous_verify_data MUST be a part of the input to the PRF. What Yoav > Nir said (XOR-ing it with the master_secret), should work (out of hand - > anybody sees a problem with it?). Yes. In Hardware Security Modules that pass certain FIPS security levels, and implement the PRF in hardware, a change to the use of the PRF that causes data (non-key material) to get combined with key material (the master secret) would require introduction of new paths, a big change, would take at least a year to get all the approvals. If you want to change inputs to the PRF, just keep keys separate from non-key data. Combine new non-key data with other existing non-key data inputs, not with key data inputs. From nelson@bolyard.me Thu Nov 26 21:58:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F2C3A67FB for ; Thu, 26 Nov 2009 21:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 qESmRUDcDnjB for ; Thu, 26 Nov 2009 21:58:35 -0800 (PST) Received: from p3plsmtpa01-01.prod.phx3.secureserver.net (p3plsmtpa01-01.prod.phx3.secureserver.net [72.167.82.81]) by core3.amsl.com (Postfix) with SMTP id 4AD713A63D3 for ; Thu, 26 Nov 2009 21:58:35 -0800 (PST) Received: (qmail 9643 invoked from network); 27 Nov 2009 05:58:29 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 27 Nov 2009 05:58:29 -0000 Message-ID: <4B0F6B04.1090103@bolyard.me> Date: Thu, 26 Nov 2009 22:00:36 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: IETF TLS Working Group References: <32C4392B-749C-47D7-B625-C769A18DE9DE@checkpoint.com> In-Reply-To: <32C4392B-749C-47D7-B625-C769A18DE9DE@checkpoint.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 05:58:36 -0000 >> On 11/26/09 12:23 , "David-Sarah Hopwood" >> wrote: >>> Blumenthal, Uri - 0662 - MITLL wrote: >>>> Yes, previous_verify_data MUST be a part of the input to the PRF. >>>> What Yoav Nir said (XOR-ing it with the master_secret), should work >>>> (out of hand - anybody sees a problem with it?). I replied to that in another message, but yes, don't mix key and non-key data together like that in the PRF definition. If you want to XOR the new data with something, or append it to something, do it with some other non-key (and non-constant) data that is input to the PRF, or else plan to replace hardware. >>> The previous_verify_data is not necessarily secret, so this requires the >>> PRF to be secure against related-key attack. The particular PRFs used in >>> SSLv3 and TLS 1.0 to 1.2 should be secure in that sense, but (if we >>> decide to use this approach) I still prefer what I suggested before: >>> >>> verify_data = >>> PRF(master_secret, finished_label, Hash(handshake_messages) >>> + previous_verify_data) >>> [0..verify_data_length-1]; >>> >>> which uses the PRF in a more conventional way. This would be OK for HSMs. It doesn't change the definition of PRF. It doesn't combine key and non-key data in a common input. It doesn't change constants that may be in silicon. On 2009-11-26 14:38 PST, Yoav Nir wrote: > I don't see why my suggestion doesn't hold for SSLv3 as well. Here's from > the spec: > > enum { client(0x434C4E54), server(0x53525652) } Sender; > > struct { > opaque md5_hash[16]; > opaque sha_hash[20]; > } Finished; > > md5_hash > MD5(master_secret + pad2 + MD5(handshake_messages + > Sender + master_secret + pad1)); > > sha_hash > SHA(master_secret + pad2 + SHA(handshake_messages + > Sender + master_secret + pad1)); > > So this could be changed in renegotiation to the following, or the Sender > field could be replaced with the contents of the previous Finished > message (it's like the finished label) > > enum { client(0x434C4E54), server(0x53525652) } Sender; > > struct { > opaque md5_hash[16]; > opaque sha_hash[20]; > } Finished; > > md5_hash > MD5(master_secret^previous_Finished_message + pad2 + > MD5(handshake_messages + > Sender + master_secret + pad1)); > > sha_hash > SHA(master_secret^previous_Finished_message + pad2 + > SHA(handshake_messages + > Sender + master_secret + pad1)); For hardware security modules that implement SSL3, that change means replacing the HSM. The only change you can make to the definitions of md5_hash and sha_hash that won't require the hardware to be replaced is to change the definition of "handshake_messages". That means somehow making the additional data part of the data stream that gets input into that MD5 or SHA function before "Sender", perhaps as if it was a pseudo handshake message. From stefan@aaa-sec.com Thu Nov 26 23:28:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855D63A6840 for ; Thu, 26 Nov 2009 23:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhLZt20UIgf9 for ; Thu, 26 Nov 2009 23:28:29 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 9C6B63A6808 for ; Thu, 26 Nov 2009 23:28:28 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D28662926DF for ; Fri, 27 Nov 2009 08:28:23 +0100 (CET) Received: (qmail 29427 invoked from network); 27 Nov 2009 07:28:21 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Nov 2009 07:28:21 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 27 Nov 2009 08:28:20 +0100 From: Stefan Santesson To: Nelson B Bolyard , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] What would be the point of removing signalling in TLS 1.3? Thread-Index: AcpvMzGfI6ileBHjWkOZco0OwzijXg== In-Reply-To: <4B0F5E6D.2050904@bolyard.me> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 07:28:30 -0000 Thanks Nelson for writing it out. This was exactly what I meant. /Stefan On 09-11-27 6:06 AM, "Nelson B Bolyard" wrote: > On 2009-11-26 13:22 PST, Marsh Ray wrote: >> Stefan Santesson wrote: >>> If you fix the Finished message calculation, making it immune to the >>> renegotiation attack, and making it the standard Finished calculation for >>> 1.3.... Then why would you need to signal that you are using the standard >>> Finished calculation? >> >> So that clients and servers can be upgraded over a period of time >> without causing interoperability problems. > > But clients and servers that are written to speak 1.3 (which doesn't exist > today) would be written to do the right thing from day 1, when they > negotiate version 1.3. There would be no "upgrade over a period of time" > for clients and servers that negotiation version 1.3. > > I'd propose the use of RI in 1.3 this way. > > A 1.3 client that also implements lesser versions MUST send RI in the client > hello, in case the server does not implement 1.3, but implements some lesser > version. > > A 1.3 server that also implements lesser versions MUST send RI in the server > hello when the client hello asks for a version less than 1.3 and the server > hello agrees to negotiate a version less than 1.3. > > A 1.3 server that receives a client hello bearing version 1.3 (or greater) > NEVER returns RI in the server hello when the server hello negotiates > version 1.3 (or greater). > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Fri Nov 27 00:54:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242353A69DE for ; Fri, 27 Nov 2009 00:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYh-QJAFg0tD for ; Fri, 27 Nov 2009 00:54:51 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 44C703A69CA for ; Fri, 27 Nov 2009 00:54:50 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 07C9E2928A9 for ; Fri, 27 Nov 2009 09:54:46 +0100 (CET) Received: (qmail 25348 invoked from network); 27 Nov 2009 08:54:43 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Nov 2009 08:54:43 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 27 Nov 2009 09:54:41 +0100 From: Stefan Santesson To: Yoav Nir Message-ID: Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQAyaHpz In-Reply-To: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 08:54:52 -0000 The current draft-ietf-tls-renegotiation-01.txt still promotes RI extension containing verify_data from previous handshake. Sorry for repeating my question, but I would be really interested to know why this is considered a better security design, than to simply send an empty RI (and to feed the values directly into Finished calculation without exchange). To me it seems obvious that the best security design is to NOT exchange this data if the objective is to verify that the parties already hold the data. It's feels like "I want proof that you hold this value, so I'm going to send it to you". /Stefan On 09-11-26 9:51 AM, "Yoav Nir" wrote: >> 1) Empty RI It's good security design >> >> If you want to make sure two parties agree on a value that they have derived >> from a previous state, in order to bind to the previous state, then why >> would you exchange that value before doing the check? >> >> On the contrary, I find it to be good security design not to exchange that >> value as it: >> >> 1) Reduce information leakage to an attacker >> 2) Increase the security assumptions that can be made based on a proof of >> matching values (good Finished messages). >> >> Even if there are no attack today to exploit the information leakage and >> exchanging the values allows secure design, I still find it valuable to >> apply the best possible security design to reduce the chance of future >> problems. > > Agree From Pasi.Eronen@nokia.com Fri Nov 27 01:17:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B0F3A69E9 for ; Fri, 27 Nov 2009 01:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 VNordErn8PX1 for ; Fri, 27 Nov 2009 01:17:55 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 279193A69E3 for ; Fri, 27 Nov 2009 01:17:55 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAR9HMfR027900; Fri, 27 Nov 2009 03:17:42 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 11:16:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 11:16:34 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 27 Nov 2009 10:16:33 +0100 From: To: , Date: Fri, 27 Nov 2009 10:16:31 +0100 Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQAyaHpzAAB4MmA= Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113EBBB@NOK-EUMSG-01.mgdnok.nokia.com> References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2009 09:16:34.0236 (UTC) FILETIME=[507CC7C0:01CA6F42] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 09:17:56 -0000 Stefan Santesson wrote: > To me it seems obvious that the best security design is to NOT > exchange this data if the objective is to verify that the parties > already hold the data. >=20 > It's feels like "I want proof that you hold this value, so I'm going > to send it to you". In many cases (such as cipher suites with NULL encryption, or some apps that use channel bindings) the verify_data values are already public. So the objective is *NOT* to prove that "I know this value"; the objective is to verify that both ends have the same value. About the obviousness of the best security design, it's safe to say=20 that when it comes to design style and preferences, people often=20 disagree. I think we're reaching "good enough" here -- if people have=20 serious concerns that the latest draft does not work, those are important, but as AD, I'm not going to give much weight to "it could be nicer" type of arguments in a situation where timely publication=20 is important.=20 Best regards, Pasi From simon@josefsson.org Fri Nov 27 01:30:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BD93A69E9 for ; Fri, 27 Nov 2009 01:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 t7SC7o6xz8Yz for ; Fri, 27 Nov 2009 01:30:26 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id CB2103A69DA for ; Fri, 27 Nov 2009 01:30:24 -0800 (PST) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAR9UDBi032325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Nov 2009 10:30:15 +0100 From: Simon Josefsson To: References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F3113EBBB@NOK-EUMSG-01.mgdnok.nokia.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091127:stefan@aaa-sec.com::HAUcUjiT6ghVV7lq:jhV X-Hashcash: 1:22:091127:pasi.eronen@nokia.com::35YAHFH8n0Gkkr49:2wWu X-Hashcash: 1:22:091127:tls@ietf.org::F3S92Hb+pTOj0JKp:FJWX X-Hashcash: 1:22:091127:ynir@checkpoint.com::rTtHqv8SX8oJfOoE:raOD Date: Fri, 27 Nov 2009 10:30:13 +0100 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3113EBBB@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Fri, 27 Nov 2009 10:16:31 +0100") Message-ID: <871vjk9uxm.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 09:30:27 -0000 writes: > Stefan Santesson wrote: > >> To me it seems obvious that the best security design is to NOT >> exchange this data if the objective is to verify that the parties >> already hold the data. >> >> It's feels like "I want proof that you hold this value, so I'm going >> to send it to you". > > > > In many cases (such as cipher suites with NULL encryption, or some > apps that use channel bindings) the verify_data values are already > public. I don't think there are "many" cases where the verify_data is public today. NULL encryption is typically disabled in all TLS stacks and there are no apps that use tls-unique channel bindings to my knowledge. Any pointers to deployed applications? /Simon From stefan@aaa-sec.com Fri Nov 27 02:02:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED93E3A67B0 for ; Fri, 27 Nov 2009 02:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUVqdNtDc6q9 for ; Fri, 27 Nov 2009 02:02:53 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 028903A685B for ; Fri, 27 Nov 2009 02:02:51 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2C19129264C for ; Fri, 27 Nov 2009 11:02:48 +0100 (CET) Received: (qmail 59736 invoked from network); 27 Nov 2009 10:02:44 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Nov 2009 10:02:44 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 27 Nov 2009 11:02:44 +0100 From: Stefan Santesson To: , Message-ID: Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQAyaHpzAAB4MmAAAeg4Sw== In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3113EBBB@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 10:02:54 -0000 Pasi, On 09-11-27 10:16 AM, "Pasi.Eronen@nokia.com" wrote: > Stefan Santesson wrote: > >> To me it seems obvious that the best security design is to NOT >> exchange this data if the objective is to verify that the parties >> already hold the data. >> >> It's feels like "I want proof that you hold this value, so I'm going >> to send it to you". > > > > In many cases (such as cipher suites with NULL encryption, or some > apps that use channel bindings) the verify_data values are already > public. So the objective is *NOT* to prove that "I know this value"; > the objective is to verify that both ends have the same value. > This is what I meant by "holding the value". The evidence thereof is degraded if you exchange the value instead of just making sure that, as you say, "both ends have the same value". > > > About the obviousness of the best security design, it's safe to say > that when it comes to design style and preferences, people often > disagree. I think we're reaching "good enough" here -- if people have > serious concerns that the latest draft does not work, those are > important, but as AD, I'm not going to give much weight to "it could > be nicer" type of arguments in a situation where timely publication > is important. > Well, I don't bring this up just because it would be a bit nicer. I bring this up since NOT exchanging verify_data seems to offer: 1) better security 2) simplicity - allows the signaling to be identical for all handshake exchanges regardless of protocol version. 3) better compatibility/easier migration towards future versions of TLS Sending the verify_data seems to offer no advantage other than to preserve the old (and agreed to vulnerable) Finished calculation instead of fixing it. I just genuinely interested to understand why we would choose the less secure and more complex option, alternatively whether I got everything totally wrong. /Stefan > Best regards, > Pasi > From uri@ll.mit.edu Fri Nov 27 05:32:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D0E3A6A44 for ; Fri, 27 Nov 2009 05:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wK0ACjN4+PPN for ; Fri, 27 Nov 2009 05:32:51 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 4EA143A6A36 for ; Fri, 27 Nov 2009 05:32:51 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nARDWgJ7013298; Fri, 27 Nov 2009 08:32:42 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAodaiMz; Fri Nov 27 08:31:57 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Fri, 27 Nov 2009 08:31:56 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'nelson@bolyard.me'" Date: Fri, 27 Nov 2009 08:31:56 -0500 Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: AcpvISo/O85VeQquR+2cbbGgJi9qmwARNMPP Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F46@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 13:32:52 -0000 QWdhaW4sIGEgdmVyeSBnb29kIHBvaW50ISBJIGFncmVlLg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCkZyb206IE5lbHNvbiBCIEJvbHlhcmQgPG5lbHNvbkBib2x5YXJkLm1lPg0K VG86IEJsdW1lbnRoYWwsIFVyaSAtIDA2NjIgLSBNSVRMTA0KQ2M6IHRsc0BpZXRmLm9yZyA8dGxz QGlldGYub3JnPg0KU2VudDogRnJpIE5vdiAyNyAwMDoyMToxMSAyMDA5ClN1YmplY3Q6IFJlOiBb VExTXSBRdWVzdCBmb3IgVW5pZmllZCBTb2x1dGlvbiB0byBUTFMgUmVuZWdvdGlhdGlvbg0KDQpP biAyMDA5LTExLTI2IDA4OjA0IFBTVCwgQmx1bWVudGhhbCwgVXJpIC0gMDY2MiAtIE1JVExMIHdy b3RlOg0KPiBZZXMsIHByZXZpb3VzX3ZlcmlmeV9kYXRhIE1VU1QgYmUgYSBwYXJ0IG9mIHRoZSBp bnB1dCB0byB0aGUgUFJGLiBXaGF0IFlvYXYNCj4gTmlyIHNhaWQgKFhPUi1pbmcgaXQgd2l0aCB0 aGUgbWFzdGVyX3NlY3JldCksIHNob3VsZCB3b3JrIChvdXQgb2YgaGFuZCAtDQo+IGFueWJvZHkg c2VlcyBhIHByb2JsZW0gd2l0aCBpdD8pLg0KDQpZZXMuICBJbiBIYXJkd2FyZSBTZWN1cml0eSBN b2R1bGVzIHRoYXQgcGFzcyBjZXJ0YWluIEZJUFMgc2VjdXJpdHkgbGV2ZWxzLA0KYW5kIGltcGxl bWVudCB0aGUgUFJGIGluIGhhcmR3YXJlLCBhIGNoYW5nZSB0byB0aGUgdXNlIG9mIHRoZSBQUkYg dGhhdA0KY2F1c2VzIGRhdGEgKG5vbi1rZXkgbWF0ZXJpYWwpIHRvIGdldCBjb21iaW5lZCB3aXRo IGtleSBtYXRlcmlhbCAodGhlIG1hc3Rlcg0Kc2VjcmV0KSB3b3VsZCByZXF1aXJlIGludHJvZHVj dGlvbiBvZiBuZXcgcGF0aHMsIGEgYmlnIGNoYW5nZSwgd291bGQgdGFrZQ0KYXQgbGVhc3QgYSB5 ZWFyIHRvIGdldCBhbGwgdGhlIGFwcHJvdmFscy4NCg0KSWYgeW91IHdhbnQgdG8gY2hhbmdlIGlu cHV0cyB0byB0aGUgUFJGLCBqdXN0IGtlZXAga2V5cyBzZXBhcmF0ZSBmcm9tDQpub24ta2V5IGRh dGEuICBDb21iaW5lIG5ldyBub24ta2V5IGRhdGEgd2l0aCBvdGhlciBleGlzdGluZyBub24ta2V5 IGRhdGENCmlucHV0cywgbm90IHdpdGgga2V5IGRhdGEgaW5wdXRzLg0K From uri@ll.mit.edu Fri Nov 27 05:44:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9DA3A69AE for ; Fri, 27 Nov 2009 05:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4I4WPjl861a for ; Fri, 27 Nov 2009 05:44:28 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id F18933A69A0 for ; Fri, 27 Nov 2009 05:44:27 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nARDiGfC015941; Fri, 27 Nov 2009 08:44:16 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAjVaygE; Fri Nov 27 08:42:06 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Fri, 27 Nov 2009 08:42:05 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'stefan@aaa-sec.com'" , "'Pasi.Eronen@nokia.com'" , "'ynir@checkpoint.com'" Date: Fri, 27 Nov 2009 08:42:05 -0500 Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQAyaHpzAAB4MmAAAeg4SwAHqUBE Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F47@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 13:44:29 -0000 U3RlZmFuIGlnbml0ZWQgbXkgY3VyaW9zaXR5Lg0KDQpXaGF0IGlzIHRoZSByZWFzb24gd2UncmUg ZXhjaGFuZ2luZyB0aGUgdmVyaWZ5X2RhdGEgdmFsdWU/DQoNCklmIG9ubHkgdG8gInNhdmUiIHRo ZSBvbGQtc3R5bGUgY2FsY3VsYXRpb24gLSBJIHZvdGUgYWdhaW5zdCBpdCwgZm9yIHRoZSByZWFz b25zIChzZWN1cml0eSkgdGhhdCBTdGVmYW4gb3V0bGluZWQuIEFuZCB3ZSdyZSBtYWtpbmcgYSBi aWcgY2hhbmdlIGFueXdheS4uLg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy b206IHRscy1ib3VuY2VzQGlldGYub3JnIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBQYXNp LkVyb25lbkBub2tpYS5jb20gPFBhc2kuRXJvbmVuQG5va2lhLmNvbT47IHluaXJAY2hlY2twb2lu dC5jb20gPHluaXJAY2hlY2twb2ludC5jb20+DQpDYzogdGxzQGlldGYub3JnIDx0bHNAaWV0Zi5v cmc+DQpTZW50OiBGcmkgTm92IDI3IDA1OjAyOjQ0IDIwMDkKU3ViamVjdDogUmU6IFtUTFNdIFZl cmlmeSBkYXRhIGluIHRoZSBSSSBleHRlbnNpb24/DQoNClBhc2ksDQoNCk9uIDA5LTExLTI3IDEw OjE2IEFNLCAiUGFzaS5Fcm9uZW5Abm9raWEuY29tIiA8UGFzaS5Fcm9uZW5Abm9raWEuY29tPiB3 cm90ZToNCg0KPiBTdGVmYW4gU2FudGVzc29uIHdyb3RlOg0KPiANCj4+IFRvIG1lIGl0IHNlZW1z IG9idmlvdXMgdGhhdCB0aGUgYmVzdCBzZWN1cml0eSBkZXNpZ24gaXMgdG8gTk9UDQo+PiBleGNo YW5nZSB0aGlzIGRhdGEgaWYgdGhlIG9iamVjdGl2ZSBpcyB0byB2ZXJpZnkgdGhhdCB0aGUgcGFy dGllcw0KPj4gYWxyZWFkeSBob2xkIHRoZSBkYXRhLg0KPj4gDQo+PiBJdCdzIGZlZWxzIGxpa2Ug Ikkgd2FudCBwcm9vZiB0aGF0IHlvdSBob2xkIHRoaXMgdmFsdWUsIHNvIEknbSBnb2luZw0KPj4g dG8gc2VuZCBpdCB0byB5b3UiLg0KPiANCj4gPG5vdCB3ZWFyaW5nIEFEIGhhdD4NCj4gDQo+IElu IG1hbnkgY2FzZXMgKHN1Y2ggYXMgY2lwaGVyIHN1aXRlcyB3aXRoIE5VTEwgZW5jcnlwdGlvbiwg b3Igc29tZQ0KPiBhcHBzIHRoYXQgdXNlIGNoYW5uZWwgYmluZGluZ3MpIHRoZSB2ZXJpZnlfZGF0 YSB2YWx1ZXMgYXJlIGFscmVhZHkNCj4gcHVibGljLiBTbyB0aGUgb2JqZWN0aXZlIGlzICpOT1Qq IHRvIHByb3ZlIHRoYXQgIkkga25vdyB0aGlzIHZhbHVlIjsNCj4gdGhlIG9iamVjdGl2ZSBpcyB0 byB2ZXJpZnkgdGhhdCBib3RoIGVuZHMgaGF2ZSB0aGUgc2FtZSB2YWx1ZS4NCj4gDQoNClRoaXMg aXMgd2hhdCBJIG1lYW50IGJ5ICJob2xkaW5nIHRoZSB2YWx1ZSIuIFRoZSBldmlkZW5jZSB0aGVy ZW9mIGlzDQpkZWdyYWRlZCBpZiB5b3UgZXhjaGFuZ2UgdGhlIHZhbHVlIGluc3RlYWQgb2YganVz dCBtYWtpbmcgc3VyZSB0aGF0LCBhcyB5b3UNCnNheSwgImJvdGggZW5kcyBoYXZlIHRoZSBzYW1l IHZhbHVlIi4NCg0KPiA8d2VhcmluZyBBRCBoYXQ+DQo+IA0KPiBBYm91dCB0aGUgb2J2aW91c25l c3Mgb2YgdGhlIGJlc3Qgc2VjdXJpdHkgZGVzaWduLCBpdCdzIHNhZmUgdG8gc2F5DQo+IHRoYXQg d2hlbiBpdCBjb21lcyB0byBkZXNpZ24gc3R5bGUgYW5kIHByZWZlcmVuY2VzLCBwZW9wbGUgb2Z0 ZW4NCj4gZGlzYWdyZWUuIEkgdGhpbmsgd2UncmUgcmVhY2hpbmcgImdvb2QgZW5vdWdoIiBoZXJl IC0tIGlmIHBlb3BsZSBoYXZlDQo+IHNlcmlvdXMgY29uY2VybnMgdGhhdCB0aGUgbGF0ZXN0IGRy YWZ0IGRvZXMgbm90IHdvcmssIHRob3NlIGFyZQ0KPiBpbXBvcnRhbnQsIGJ1dCBhcyBBRCwgSSdt IG5vdCBnb2luZyB0byBnaXZlIG11Y2ggd2VpZ2h0IHRvICJpdCBjb3VsZA0KPiBiZSBuaWNlciIg dHlwZSBvZiBhcmd1bWVudHMgaW4gYSBzaXR1YXRpb24gd2hlcmUgdGltZWx5IHB1YmxpY2F0aW9u DQo+IGlzIGltcG9ydGFudC4gDQo+IA0KDQpXZWxsLCBJIGRvbid0IGJyaW5nIHRoaXMgdXAganVz dCBiZWNhdXNlIGl0IHdvdWxkIGJlIGEgYml0IG5pY2VyLg0KDQpJIGJyaW5nIHRoaXMgdXAgc2lu Y2UgTk9UIGV4Y2hhbmdpbmcgdmVyaWZ5X2RhdGEgc2VlbXMgdG8gb2ZmZXI6DQoNCjEpIGJldHRl ciBzZWN1cml0eSANCjIpIHNpbXBsaWNpdHkgLSBhbGxvd3MgdGhlIHNpZ25hbGluZyB0byBiZSBp ZGVudGljYWwgZm9yIGFsbCBoYW5kc2hha2UNCmV4Y2hhbmdlcyByZWdhcmRsZXNzIG9mIHByb3Rv Y29sIHZlcnNpb24uDQozKSBiZXR0ZXIgY29tcGF0aWJpbGl0eS9lYXNpZXIgbWlncmF0aW9uIHRv d2FyZHMgZnV0dXJlIHZlcnNpb25zIG9mIFRMUw0KDQpTZW5kaW5nIHRoZSB2ZXJpZnlfZGF0YSBz ZWVtcyB0byBvZmZlciBubyBhZHZhbnRhZ2Ugb3RoZXIgdGhhbiB0byBwcmVzZXJ2ZQ0KdGhlIG9s ZCAoYW5kIGFncmVlZCB0byB2dWxuZXJhYmxlKSBGaW5pc2hlZCBjYWxjdWxhdGlvbiBpbnN0ZWFk IG9mIGZpeGluZw0KaXQuDQoNCkkganVzdCBnZW51aW5lbHkgaW50ZXJlc3RlZCB0byB1bmRlcnN0 YW5kIHdoeSB3ZSB3b3VsZCBjaG9vc2UgdGhlIGxlc3MNCnNlY3VyZSBhbmQgbW9yZSBjb21wbGV4 IG9wdGlvbiwgYWx0ZXJuYXRpdmVseSB3aGV0aGVyIEkgZ290IGV2ZXJ5dGhpbmcNCnRvdGFsbHkg d3JvbmcuIA0KDQovU3RlZmFuDQoNCg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFBhc2kNCj4gDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWls aW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHMNCg== From mrex@sap.com Fri Nov 27 06:01:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1303A6A48 for ; Fri, 27 Nov 2009 06:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 vPi1viGdl1qy for ; Fri, 27 Nov 2009 06:01:31 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 48D663A67B6 for ; Fri, 27 Nov 2009 06:01:31 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARE1LP1011663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 15:01:21 +0100 (MET) From: Martin Rex Message-Id: <200911271356.nARDuKVE026997@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 27 Nov 2009 14:56:20 +0100 (MET) In-Reply-To: <4B0F6B04.1090103@bolyard.me> from "Nelson B Bolyard" at Nov 26, 9 10:00:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 14:01:32 -0000 Nelson B Bolyard wrote: > > For hardware security modules that implement SSL3, that change means > replacing the HSM. The only change you can make to the definitions of > md5_hash and sha_hash that won't require the hardware to be replaced is > to change the definition of "handshake_messages". That means somehow > making the additional data part of the data stream that gets input into > that MD5 or SHA function before "Sender", perhaps as if it was a pseudo > handshake message. Which is one of the reasons why I'm favouring to expand the definition of handshake messages for renegotiation and _NOT_ touch the PRF or do other fancy stuff. The one thing that SSLv3 and TLS have in common is the concept of handshake message hash (a lot of other stuff changed significantly). The handshake message hash is also the thing that goes into both, Finished and CertificateVerify. -Martin From Pasi.Eronen@nokia.com Fri Nov 27 06:10:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77653A68C8 for ; Fri, 27 Nov 2009 06:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 xz8bWSrfWSc4 for ; Fri, 27 Nov 2009 06:10:35 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 203863A6839 for ; Fri, 27 Nov 2009 06:10:34 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nARE9njt003916; Fri, 27 Nov 2009 16:10:11 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 16:10:05 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 16:10:00 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 27 Nov 2009 15:09:59 +0100 From: To: , Date: Fri, 27 Nov 2009 15:09:58 +0100 Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQAyaHpzAAB4MmAAAeg4SwAIKiIw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3113EBBB@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2009 14:10:00.0301 (UTC) FILETIME=[4E8519D0:01CA6F6B] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 14:10:38 -0000 Stefan Santesson wrote: > Well, I don't bring this up just because it would be a bit nicer. >=20 > I bring this up since NOT exchanging verify_data seems to offer: >=20 > 1) better security > 2) simplicity - allows the signaling to be identical for all handshake > exchanges regardless of protocol version. > 3) better compatibility/easier migration towards future versions of TLS IMHO all these are your opinions, not facts (in some cases, my personal opinion could be the same as yours, though -- but that doesn't mean everyone else agrees, too). This *might* bring better security if you assume implementors that are stupid in a very particular way. But if they're stupid in some other way, there's necessarily no difference. And seriously speaking, the=20 current draft is so simple that if an implementor can't get it right, he/she has no business in implementing security-critical components... For simplicity, the current draft is already very simple, and IMHO it's not clear that continuing to tweak it has a positive return on investment, considering it delays the publication.=20 About future versions of TLS, IMHO it's quite difficult to predict which would be most compatible. What if, e.g., the next version of TLS decides that sending certificates in the clear wasn't that great idea, and nowadays we can afford to do Diffie-Hellman before doing any authentication? This could completely change all the handshake messages after ClientHello, and the current functionality of "Finished" could be done in quite different way..=20 (I'm not suggesting that TLS 1.3/2.0 should do that -- just that we don't know what it will do yet.)=20 Best regards, Pasi (not wearing any hats)=20 From Pasi.Eronen@nokia.com Fri Nov 27 06:16:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF8A3A6A26 for ; Fri, 27 Nov 2009 06:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 uCSxA+xqxgPB for ; Fri, 27 Nov 2009 06:16:51 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 388E83A694A for ; Fri, 27 Nov 2009 06:16:51 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAREGe2N000866; Fri, 27 Nov 2009 08:16:44 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 16:16:38 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 16:16:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 16:16:33 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 27 Nov 2009 15:16:33 +0100 From: To: Date: Fri, 27 Nov 2009 15:16:31 +0100 Thread-Topic: Verify data in the RI extension? Thread-Index: AcpvREj2aiKSpBNNSkmR+moVY/3Y9AAJ2Umg Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113EEE8@NOK-EUMSG-01.mgdnok.nokia.com> References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F3113EBBB@NOK-EUMSG-01.mgdnok.nokia.com> <871vjk9uxm.fsf@mocca.josefsson.org> In-Reply-To: <871vjk9uxm.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2009 14:16:33.0965 (UTC) FILETIME=[392975D0:01CA6F6C] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 14:16:52 -0000 Simon Josefsson wrote: > I don't think there are "many" cases where the verify_data is public > today. NULL encryption is typically disabled in all TLS stacks and > there are no apps that use tls-unique channel bindings to my knowledge. > Any pointers to deployed applications? Not really. SCRAM (currently in RFC Ed queue) will use it. Perhaps OAUTH WG will use it, too. Best regards, Pasi From mrex@sap.com Fri Nov 27 06:30:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B93A3A6A59 for ; Fri, 27 Nov 2009 06:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 q+BbnjlNrDt4 for ; Fri, 27 Nov 2009 06:30:27 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 373BD3A68B8 for ; Fri, 27 Nov 2009 06:30:27 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAREUAFT018473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 15:30:10 +0100 (MET) From: Martin Rex Message-Id: <200911271425.nAREP95E028727@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Fri, 27 Nov 2009 15:25:09 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 27, 9 03:09:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 14:30:28 -0000 Pasi.Eronen@nokia.com wrote: > > For simplicity, the current draft is already very simple, and IMHO > it's not clear that continuing to tweak it has a positive return > on investment, considering it delays the publication. Not really. I ask this before: what should the original designers of the SSLv3 renegotiation have done from the beginning to make it secure. Invent TLS extensions and then a TLS extension RI is definitely _not_ the answer. They would have fixed the handshake message hash from the beginning. The "dirty ugly" signaling is a patch for a "dirty ugly" security problem in "dirty old" implementations of a "dirty old" protocol. We need it to distinguish old from updated implementations and for supporting interop with old -- otherwise we could just change both handshake algorithms (like including different finished labels) and make the fix entirely without on-the-wire changes, no signaling, but also no interop with the installed base. > > About future versions of TLS, IMHO it's quite difficult to predict which > would be most compatible. What if, e.g., the next version of TLS > decides that sending certificates in the clear wasn't that great idea, > and nowadays we can afford to do Diffie-Hellman before doing any > authentication? This could completely change all the handshake > messages after ClientHello, and the current functionality of "Finished" > could be done in quite different way.. If it does not retain (Extended)ServerHello, then it will actually kill a lot of the existing SSL/TLS protocol features -- and reliably kill TLS extension RI with it. The handshake message hash is one of the basic concepts of the SSL/TLS protocol. If that is changed, then you basically have none of the original protocol left. Therefore directly feeding into the handshake message hash is the more conservative and forward compatible approach. -Martin From n.mavrogiannopoulos@gmail.com Fri Nov 27 06:30:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD963A6A66 for ; Fri, 27 Nov 2009 06:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 MbeeSM4FqK5G for ; Fri, 27 Nov 2009 06:30:50 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id EA7C43A6A60 for ; Fri, 27 Nov 2009 06:30:49 -0800 (PST) Received: by ewy6 with SMTP id 6so641862ewy.29 for ; Fri, 27 Nov 2009 06:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=sxPzsgPJIDjNvQbW9SoOIrT3p09mz0yxvmBUpMQC07U=; b=iASGOD6/04fgjwGr0iWY0Rf9n+PBLjCndHDNI0KalX4svf2KuMN70OQYKTor6splha gCpu8ZP+kzVe/dNIFglYOaOKKCIxYkH0Ib5I9TlsTplgA3+ShdaDAf2VcJKf71uj7zE0 qUfJc5x39rJCUjBhHNVDBfihzxXLG1ixcLOp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=okwr/3OeMBOMx7SZ5mn9ZiBae4a5dT4EO6nuLhN8o9U+xWNGdTqfSMuuqn1ylAJi1/ 8DofGQ7mopwGkIg9flewXhwR3ZVjhG/QRPlDLRo4nK9N4964tZtCRnQFtpQAW4CxCGAP Ft0zMavq6r3lZChMq6MgrdTnD+3i+qzt3SxQE= MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.213.23.146 with SMTP id r18mr1194104ebb.79.1259332239566; Fri, 27 Nov 2009 06:30:39 -0800 (PST) In-Reply-To: References: <20091125223502.4265B6C3285@kilo.networkresonance.com> Date: Fri, 27 Nov 2009 16:30:39 +0200 X-Google-Sender-Auth: bd4060a291f9f974 Message-ID: From: Nikos Mavrogiannopoulos To: Stefan Santesson Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 14:30:51 -0000 On Thu, Nov 26, 2009 at 10:28 AM, Stefan Santesson wrote: > On the contrary, I find it to be good security design not to exchange that > value as it: > > 1) Reduce information leakage to an attacker Hello, How would that be? What scenario do you have in mind? This value has already been exchanged in the initial finished message exchange and was protected under the same ciphersuite. Why would this exchange be less secure? If the attacker can decrypt and see this value, then he can also see the initial finished value. No new information is given to him. regards, Nikos From stefan@aaa-sec.com Fri Nov 27 07:00:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F418A3A6894 for ; Fri, 27 Nov 2009 07:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SUZ1aGgo3op for ; Fri, 27 Nov 2009 07:00:49 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 1295B3A6887 for ; Fri, 27 Nov 2009 07:00:47 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6B9E728BD90 for ; Fri, 27 Nov 2009 16:00:45 +0100 (CET) Received: (qmail 26712 invoked from network); 27 Nov 2009 15:00:39 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Nov 2009 15:00:39 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 27 Nov 2009 16:00:38 +0100 From: Stefan Santesson To: , Message-ID: Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpudZ/T2dP4yiUOQNiqr1jShi/VuQAyaHpzAAB4MmAAAeg4SwAIKiIwAAI9Tak= In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:00:50 -0000 Pasi, On 09-11-27 3:09 PM, "Pasi.Eronen@nokia.com" wrote: > For simplicity, the current draft is already very simple, and IMHO > it's not clear that continuing to tweak it has a positive return > on investment, considering it delays the publication. It's not a matter of tweaking, This working group discussion has produced 2 proposals. If you count in changes that is about to be applied to Marin's document the following apply: 1) Both proposals agree on the same initial signaling (cipher suite for C->S and empty RI for S->C) 2) For renegotiations: a) Martin's draft propose to update (fix) the Finished calculation and use the same signaling as in 1). b) Eric's draft suggest sending verify_data in RI extensions and keep the old Finished calculation. Many members of this list argue that 2a has better security properties and is simpler to deploy (especially for legacy implementations). The arguments for 2b seems to be that it is "good enough" and "why should we care about old legacy implementations". Now, maybe I'm wrong about that, but wouldn't it at least be fair to ask the working group which approach they prefer? /Stefan From ekr@networkresonance.com Fri Nov 27 07:10:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DE13A68D8 for ; Fri, 27 Nov 2009 07:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgk4w5ttVF5H for ; Fri, 27 Nov 2009 07:10:34 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id C37F83A6836 for ; Fri, 27 Nov 2009 07:10:34 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id BDEF16C3795; Fri, 27 Nov 2009 07:11:13 -0800 (PST) Date: Fri, 27 Nov 2009 07:11:12 -0800 From: Eric Rescorla To: Stefan Santesson In-Reply-To: References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091127151113.BDEF16C3795@kilo.networkresonance.com> Cc: "tls@ietf.org" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:10:36 -0000 At Fri, 27 Nov 2009 09:54:41 +0100, Stefan Santesson wrote: > > The current draft-ietf-tls-renegotiation-01.txt still promotes RI extension > containing verify_data from previous handshake. > > Sorry for repeating my question, but I would be really interested to know > why this is considered a better security design, than to simply send an > empty RI (and to feed the values directly into Finished calculation without > exchange). I think I answered this question with my view in an earlier message: This requires breaking the current clean definition of handshake hashes as the hash of all the handshake messages and simply adding some synthetic message in the middle. I don't think this is anywhere near as clean, as evidenced by the ongoing debate about whether to put it the synthetic data in the front, the back, incorporate it into the PRF, or chain the pre-existing handshake messages. [FWIW, I think I prefer the last of these implicit versions.] By contrast, RI allows that part of the system (which is well understood) to remain the same and in fact when RI is offered on the first handshake, there is no change to the TLS core at all. It's all just hashed into Finished as part of the ordinary TLS procedures, and everything is in fact compliant TLS, which I think is desirable. I appreciate that this is to some extent a matter of tradeoffs, but I don't find the arguments in favor of the implicit version very compelling when weighed against the above. I also share David Hopwood's concern about ambiguity in the handshake hashes stream created by having data which is not properly formatted injected into the hash (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html), so I don't think the particular approach in Martin's draft is really satisfactory. This isn't to say that one couldn't design a mechanism that didn't carry the signaling data over the wire--one obviously could. However, when I look back over the 50 or so messages that were sent to the list yesterday, a large fraction of them are various tweaks on exactly how incorporate that data, which suggests to me that this approach isn't at all easy to reason about. -Ekr From stefan@aaa-sec.com Fri Nov 27 07:10:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09A23A6939 for ; Fri, 27 Nov 2009 07:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDkIkcptvbK3 for ; Fri, 27 Nov 2009 07:10:54 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id BA5FC3A6937 for ; Fri, 27 Nov 2009 07:10:54 -0800 (PST) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0347D28E513 for ; Fri, 27 Nov 2009 16:09:03 +0100 (CET) Received: (qmail 77902 invoked from network); 27 Nov 2009 15:08:57 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Nov 2009 15:08:57 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 27 Nov 2009 16:08:54 +0100 From: Stefan Santesson To: Nikos Mavrogiannopoulos Message-ID: Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: Acpvc4jE620w47b2q0Wv2QktN+7MpA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:10:55 -0000 No I don't have any scenario (and I said so). This was part of a principal (theoretical) argument. /Stefan On 09-11-27 3:30 PM, "Nikos Mavrogiannopoulos" wrote: > On Thu, Nov 26, 2009 at 10:28 AM, Stefan Santesson wrote: > >> On the contrary, I find it to be good security design not to exchange that >> value as it: >> >> 1) Reduce information leakage to an attacker > > Hello, > How would that be? What scenario do you have in mind? This value has > already been exchanged in the initial finished message exchange and > was protected under the same ciphersuite. Why would this exchange be > less secure? If the attacker can decrypt and see this value, then he > can also see the initial finished value. No new information is given > to him. > > > regards, > Nikos From ekr@networkresonance.com Fri Nov 27 07:21:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05C73A689B for ; Fri, 27 Nov 2009 07:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.095 X-Spam-Level: X-Spam-Status: No, score=0.095 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZgbuZH+jT1X for ; Fri, 27 Nov 2009 07:21:57 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 15D9F3A6836 for ; Fri, 27 Nov 2009 07:21:57 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 1F1176C3796; Fri, 27 Nov 2009 07:22:35 -0800 (PST) Date: Fri, 27 Nov 2009 07:22:35 -0800 From: Eric Rescorla To: Stefan Santesson In-Reply-To: References: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091127152236.1F1176C3796@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:21:57 -0000 At Fri, 27 Nov 2009 16:00:38 +0100, Stefan Santesson wrote: > Many members of this list argue that 2a has better security properties and > is simpler to deploy (especially for legacy implementations). > The arguments for 2b seems to be that it is "good enough" and "why should we > care about old legacy implementations". I don't think this characterizes my position particularly well: - I don't think that having the data not carried in the message obviously has better security properties. There may be some version that clearly does, but I haven't seen it yet. My suspicion is that the "best" versions of each of these approaches have equivalent security, but as I said in a previous message, I'm concerned about the specific "implicit" versions I've seen proposed. [For the record: your argument about reducing information leakage is, AFAICT, incorrect. The verify_data in the Finished is carried over the same encrypted channel as the new handshake messages. Any attacker who can see the second can see the first.] - I don't agree that it's simpler to deploy versions that don't carry the verify_data in an extension. It may require fewer lines of code (though honestly, the number of lines we're talking about here is so few, it hardly matters), but on the other hand, the lines of code are in core pieces of TLS, not in peripheral pieces. - I'm not sure where you get the idea that carrying the verify_data in an extension somehow involves not caring about legacy implementations. Perhaps you and I have different views of what that would involve. As I observed earlier, TLS connections that use RI (and not the magic cipher suite) are fully compliant with all existing TLS RFCs. That seems pretty legacy-friendly to me. In short, I don't think that signaling the previous verify_data in the extension is merely "good enough". I think it's better. -Ekr From mrex@sap.com Fri Nov 27 07:23:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29C13A6822 for ; Fri, 27 Nov 2009 07:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 NdZZDtB4S4pS for ; Fri, 27 Nov 2009 07:23:52 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id EAEC73A681B for ; Fri, 27 Nov 2009 07:23:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARFNbaq000345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 16:23:37 +0100 (MET) From: Martin Rex Message-Id: <200911271523.nARFNaeE002169@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Fri, 27 Nov 2009 16:23:36 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 27, 9 03:09:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:23:53 -0000 Pasi.Eronen@nokia.com wrote: > > For simplicity, the current draft is already very simple, and IMHO > it's not clear that continuing to tweak it has a positive return > on investment, considering it delays the publication. We should _not_ rush it out. The message that I'm getting from people doing maintenance of old installed base is that it is not easy for them to make an assessment about TLS extension RI. The spec is from a high level view. For implementations that don't support TLS extensions, you can only find out and what it means in terms of code changes when you try to implement it--not from that draft. When I (re)wrote my I-D, I tried to describe all the necessary code changes in order to implement it. Well, OK, it's a little more than that, more like a "nanny" spec. It should _not_ be a question how beautiful the solution is and how well it fits into new implementations, but primarily, that it fits equally well even the oldest implementations around, and that it is easy for them to implement, otherwise we are not going to see the widespread adoption that we need. -Martin From ekr@networkresonance.com Fri Nov 27 07:24:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F603A69EC for ; Fri, 27 Nov 2009 07:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hw+ZWT4dRl2O for ; Fri, 27 Nov 2009 07:24:09 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id A918E3A691B for ; Fri, 27 Nov 2009 07:24:09 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 4B60A6C3797; Fri, 27 Nov 2009 07:24:48 -0800 (PST) Date: Fri, 27 Nov 2009 07:24:48 -0800 From: Eric Rescorla To: Stefan Santesson In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091127152448.4B60A6C3797@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:24:10 -0000 At Fri, 27 Nov 2009 16:08:54 +0100, Stefan Santesson wrote: > > No I don't have any scenario (and I said so). > > This was part of a principal (theoretical) argument. As Nikos says, I don't see how this argument has any force: The basic design of TLS rehandshaking is that it's performed over the same channel as the original handshake. Therefore, by definition the attacker already has the contents of the immediately previous Finished. -Ekr > On 09-11-27 3:30 PM, "Nikos Mavrogiannopoulos" wrote: > > > On Thu, Nov 26, 2009 at 10:28 AM, Stefan Santesson wrote: > > > >> On the contrary, I find it to be good security design not to exchange that > >> value as it: > >> > >> 1) Reduce information leakage to an attacker > > > > Hello, > > How would that be? What scenario do you have in mind? This value has > > already been exchanged in the initial finished message exchange and > > was protected under the same ciphersuite. Why would this exchange be > > less secure? If the attacker can decrypt and see this value, then he > > can also see the initial finished value. No new information is given > > to him. > > > > > > regards, > > Nikos > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Fri Nov 27 07:27:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8C53A6951 for ; Fri, 27 Nov 2009 07:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 DoLmdxJjkhbQ for ; Fri, 27 Nov 2009 07:27:12 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2685F3A691B for ; Fri, 27 Nov 2009 07:27:11 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARFR4Ju013863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 16:27:04 +0100 (MET) From: Martin Rex Message-Id: <200911271527.nARFR39f002291@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 27 Nov 2009 16:27:03 +0100 (MET) In-Reply-To: <20091127151113.BDEF16C3795@kilo.networkresonance.com> from "Eric Rescorla" at Nov 27, 9 07:11:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:27:13 -0000 Eric Rescorla wrote: > > I also share David Hopwood's concern about ambiguity in the handshake > hashes stream created by having data which is not properly formatted > injected into the hash > (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html), > so I don't think the particular approach in Martin's draft is > really satisfactory. That problem can be trivially fixed. We just memorize the non-encrypted Client.Finished and Server.Finished handshake messages in full, rather then just the contained verify_data. -Martin From mrex@sap.com Fri Nov 27 07:41:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362A23A6831 for ; Fri, 27 Nov 2009 07:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 jIFN-ATFRJzx for ; Fri, 27 Nov 2009 07:41:24 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 458E83A6784 for ; Fri, 27 Nov 2009 07:41:24 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARFfGsE013624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 16:41:16 +0100 (MET) From: Martin Rex Message-Id: <200911271541.nARFfFRW003125@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 27 Nov 2009 16:41:15 +0100 (MET) In-Reply-To: <20091127151113.BDEF16C3795@kilo.networkresonance.com> from "Eric Rescorla" at Nov 27, 9 07:11:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:41:25 -0000 Eric Rescorla wrote: > > This requires breaking the current clean definition of handshake > hashes as the hash of all the handshake messages and simply adding > some synthetic message in the middle. "The current clean definition" of the handshake message hash is what has gotten us into the trouble. So we are not breaking it, we are fixing it. We're not doing any wire-format changes, so implementations that have not implemented renegotiation at all are not even affected by this change. That is definitely much cleaner as having everyone run around with a band-aid on their ClientHello and ServerHello handshake messages when renegotiating. It's encrypted, so most people will not see it, but it's still there! I don't think this is anywhere > near as clean, as evidenced by the ongoing debate about whether to put > it the synthetic data in the front, the back, incorporate it into the > PRF, or chain the pre-existing handshake messages. [FWIW, I think I > prefer the last of these implicit versions.] Making a rarely-used option that came several years after most of the currently installed base a retroactive mandatory-to-implement feature of the protocol, THAT is dirty and ugly. -Martin From mrex@sap.com Fri Nov 27 07:51:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7123A6970 for ; Fri, 27 Nov 2009 07:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 YKFRA0t6q4HL for ; Fri, 27 Nov 2009 07:51:47 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E9D3F3A6925 for ; Fri, 27 Nov 2009 07:51:46 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARFpdQ5020871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 16:51:39 +0100 (MET) From: Martin Rex Message-Id: <200911271551.nARFpcgv003797@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 27 Nov 2009 16:51:38 +0100 (MET) In-Reply-To: <20091127151113.BDEF16C3795@kilo.networkresonance.com> from "Eric Rescorla" at Nov 27, 9 07:11:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:51:48 -0000 Eric Rescorla wrote: > > This isn't to say that one couldn't design a mechanism that didn't > carry the signaling data over the wire--one obviously could. > However, when I look back over the 50 or so messages that were > sent to the list yesterday, a large fraction of them are various > tweaks on exactly how incorporate that data, which suggests to > me that this approach isn't at all easy to reason about. We just carry the original handshake messages and be done with it. As David outlined stripping the original message header from the verify_data wasn't such a good idea, because it opens a theoretical possibility of an attack. Fine, we leave the header on. Messing around with the PRF, that is ideas from implementors that never came in contact with FIPS 140-2 and interfaces to crypto hardware and requirements around that. And it would make everything much more complicated because of the differences between SSLv3 and TLS. Adding the previous Finished messages at the very beginning of the handshake message hash is less straight-forward. When the client sends the renegotiation ClientHello, it must have previously sent the Client.Finished, so we could add that, however it may have not yet received the Server.Finished from the previous handshake, so this must go into the handshake message hash after ClientHello in order to be on the safe side. -Martin From stefan@aaa-sec.com Fri Nov 27 07:53:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B483A685E for ; Fri, 27 Nov 2009 07:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OGGeZIa3UU9 for ; Fri, 27 Nov 2009 07:53:22 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id D44B83A6858 for ; Fri, 27 Nov 2009 07:53:21 -0800 (PST) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 19B8B28A39F for ; Fri, 27 Nov 2009 16:53:11 +0100 (CET) Received: (qmail 30921 invoked from network); 27 Nov 2009 15:53:05 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Nov 2009 15:53:05 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 27 Nov 2009 16:53:03 +0100 From: Stefan Santesson To: Eric Rescorla Message-ID: Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpvebOy8kAeBIOUO0aq7ye2h2EeIg== In-Reply-To: <20091127152236.1F1176C3796@kilo.networkresonance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:53:23 -0000 Eric, Thanks for the straightforward reply. In-line; On 09-11-27 4:22 PM, "Eric Rescorla" wrote: > At Fri, 27 Nov 2009 16:00:38 +0100, > Stefan Santesson wrote: >> Many members of this list argue that 2a has better security properties and >> is simpler to deploy (especially for legacy implementations). >> The arguments for 2b seems to be that it is "good enough" and "why should we >> care about old legacy implementations". > > I don't think this characterizes my position particularly well: > > - I don't think that having the data not carried in the message obviously > has better security properties. There may be some version that clearly > does, but I haven't seen it yet. My suspicion is that the "best" versions > of each of these approaches have equivalent security, but as I said > in a previous message, I'm concerned about the specific "implicit" > versions I've seen proposed. > I have a hard time believing that it would be a hard to define a structure for inclusion of past verify_data that would work for implicit inclusion. The real security advantage of implicit is that you know that the opponent actually derived the same value from previous handshake. By sending it in RI you don't know if the opponent just blindly accepted what you sent without checking it. I think that is a significant security advantage for the implicit approach. > [For the record: your argument about reducing information leakage > is, AFAICT, incorrect. The verify_data in the Finished is carried > over the same encrypted channel as the new handshake messages. Any > attacker who can see the second can see the first.] > We can disregard that comment for this discussion. For this I agree with you. > > - I don't agree that it's simpler to deploy versions that don't carry the > verify_data in an extension. It may require fewer lines of code > (though honestly, the number of lines we're talking about here > is so few, it hardly matters), but on the other hand, the lines > of code are in core pieces of TLS, not in peripheral pieces. > > > - I'm not sure where you get the idea that carrying the verify_data > in an extension somehow involves not caring about legacy implementations. > Perhaps you and I have different views of what that would involve. > As I observed earlier, TLS connections that use RI (and not the magic > cipher suite) are fully compliant with all existing TLS RFCs. > That seems pretty legacy-friendly to me. > An RI from the client containing verify_data need to be parsed and values have to be extracted by the server. This means requirement to add extension handling at the server side for all versions of SSLv3 -> TLS 1.2. In the alternative solution no server need to be bothered with parsing extensions. Some people mean that this is much easier to implement for legacy implementations. I just find their arguments convincing. > > In short, I don't think that signaling the previous verify_data in the > extension is merely "good enough". I think it's better. > Fair enough. I'm afraid I still disagree. /Stefan > -Ekr From ekr@networkresonance.com Fri Nov 27 07:53:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57AAE3A694A for ; Fri, 27 Nov 2009 07:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwh88llmwL1G for ; Fri, 27 Nov 2009 07:53:44 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9326B3A693A for ; Fri, 27 Nov 2009 07:53:44 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9E8B86C37B6; Fri, 27 Nov 2009 07:54:23 -0800 (PST) Date: Fri, 27 Nov 2009 07:54:22 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911271541.nARFfFRW003125@fs4113.wdf.sap.corp> References: <20091127151113.BDEF16C3795@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091127155423.9E8B86C37B6@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:53:45 -0000 At Fri, 27 Nov 2009 16:41:15 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > This requires breaking the current clean definition of handshake > > hashes as the hash of all the handshake messages and simply adding > > some synthetic message in the middle. > > "The current clean definition" of the handshake message hash is > what has gotten us into the trouble. I don't agree with this assessment of what the problem is. > That > is definitely much cleaner as having everyone run around with > a band-aid on their ClientHello and ServerHello handshake > messages when renegotiating. It's encrypted, so most people > will not see it, but it's still there! Yes it's still there. So what? Obviously, you and I have different opinions about what's "clean". > I don't think this is anywhere > > near as clean, as evidenced by the ongoing debate about whether to put > > it the synthetic data in the front, the back, incorporate it into the > > PRF, or chain the pre-existing handshake messages. [FWIW, I think I > > prefer the last of these implicit versions.] > > Making a rarely-used option that came several years after most of > the currently installed base a retroactive mandatory-to-implement > feature of the protocol, THAT is dirty and ugly. This seems like a generalized argument against using extensions at all, not against putting the verify_data in the handshake. -Ekr From ekr@networkresonance.com Fri Nov 27 07:54:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0653A691E for ; Fri, 27 Nov 2009 07:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcikiZMV7qwU for ; Fri, 27 Nov 2009 07:54:49 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 911A33A68F2 for ; Fri, 27 Nov 2009 07:54:49 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id CE07A6C37B7; Fri, 27 Nov 2009 07:55:28 -0800 (PST) Date: Fri, 27 Nov 2009 07:55:28 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911271523.nARFNaeE002169@fs4113.wdf.sap.corp> References: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091127155528.CE07A6C37B7@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:54:50 -0000 At Fri, 27 Nov 2009 16:23:36 +0100 (MET), Martin Rex wrote: > > Pasi.Eronen@nokia.com wrote: > > > > For simplicity, the current draft is already very simple, and IMHO > > it's not clear that continuing to tweak it has a positive return > > on investment, considering it delays the publication. > > We should _not_ rush it out. > > The message that I'm getting from people doing maintenance of > old installed base is that it is not easy for them to make > an assessment about TLS extension RI. The spec is from a high > level view. For implementations that don't support TLS extensions, > you can only find out and what it means in terms of code changes > when you try to implement it--not from that draft. Hmm... This doesn't seem that hard to work out. In any case, I'd certainly be willing to add a non-normative appendix describing the minimal code changes necessary. > It should _not_ be a question how beautiful the solution is and how well it > fits into new implementations, but primarily, that it fits equally > well even the oldest implementations around, and that it is easy > for them to implement, otherwise we are not going to see the > widespread adoption that we need. I'm not sure I buy this: the vast majority of TLS implementations run one of a small number of stacks (SChannel, OpenSSL, NSS). The pace of adoption is going to be primarily driven by (1) how fast those stacks implement this new functionality and (2) the base (very slow) rate at which people upgrade their stacks [Res03]. Whether or not a stack that has <1% of the market upgrades only has a very small impact on how widespread deployment is. This isn't to say that we shouldn't be concerned with whether what we do can be incorporated into old systems, but I don't really agree that easy incorporation into such systems ought to be our highest design priority. -Ekr [Res03] E. Rescorla, "Security Holes... Who cares?", Proceedings of the 12th USENIX Security Symposium, August 2003. From mrex@sap.com Fri Nov 27 08:15:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDD93A69C0 for ; Fri, 27 Nov 2009 08:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.772 X-Spam-Level: X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_CODEINE=0.833] 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 6QguXNNPbj0H for ; Fri, 27 Nov 2009 08:15: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 24E243A6970 for ; Fri, 27 Nov 2009 08:15:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARGF9AI012978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 17:15:09 +0100 (MET) From: Martin Rex Message-Id: <200911271615.nARGF8uT005350@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 27 Nov 2009 17:15:08 +0100 (MET) In-Reply-To: <20091127155528.CE07A6C37B7@kilo.networkresonance.com> from "Eric Rescorla" at Nov 27, 9 07:55:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:15:17 -0000 Eric Rescorla wrote: > > > It should _not_ be a question how beautiful the solution is and how well it > > fits into new implementations, but primarily, that it fits equally > > well even the oldest implementations around, and that it is easy > > for them to implement, otherwise we are not going to see the > > widespread adoption that we need. > > I'm not sure I buy this: the vast majority of TLS implementations run > one of a small number of stacks (SChannel, OpenSSL, NSS). You're only looking at WebServers and WebBrowsers. Maybe because Statistics like Netcraft have such a limited perception. Btw. these "small number of stacks" is in reality a larger number of independently maintained codelines. Schannel may be ~30, OpenSSL is probably >> 500, and most of them are quite old. There are probably several independent SSL implementations for Java. -Martin From ekr@networkresonance.com Fri Nov 27 08:16:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0283A6970 for ; Fri, 27 Nov 2009 08:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.07 X-Spam-Level: X-Spam-Status: No, score=0.07 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubIgxnt3mMSP for ; Fri, 27 Nov 2009 08:16:44 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 591623A682A for ; Fri, 27 Nov 2009 08:16:44 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3DF546C37C8; Fri, 27 Nov 2009 08:17:24 -0800 (PST) Date: Fri, 27 Nov 2009 08:17:24 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911271527.nARFR39f002291@fs4113.wdf.sap.corp> References: <20091127151113.BDEF16C3795@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091127161724.3DF546C37C8@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:16:45 -0000 At Fri, 27 Nov 2009 16:27:03 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > I also share David Hopwood's concern about ambiguity in the handshake > > hashes stream created by having data which is not properly formatted > > injected into the hash > > (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html), > > so I don't think the particular approach in Martin's draft is > > really satisfactory. > > That problem can be trivially fixed. > > We just memorize the non-encrypted Client.Finished and Server.Finished > handshake messages in full, rather then just the contained verify_data. Woah, that's scary.... We're going to take the exact messages that previously appeared on the wire and inject them into the handshake hashes in order to *reduce* ambiguity in the hash input stream? I mean, maybe that's OK, but it sure isn't obviously OK. -Ekr From mrex@sap.com Fri Nov 27 08:34:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E3F3A6928 for ; Fri, 27 Nov 2009 08:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 eDvKDjQgk1Od for ; Fri, 27 Nov 2009 08:34:30 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id CFD9F3A693A for ; Fri, 27 Nov 2009 08:34:29 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARGYL9d015086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 17:34:21 +0100 (MET) From: Martin Rex Message-Id: <200911271634.nARGYKm1006390@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 27 Nov 2009 17:34:20 +0100 (MET) In-Reply-To: <20091127161724.3DF546C37C8@kilo.networkresonance.com> from "Eric Rescorla" at Nov 27, 9 08:17:24 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:34:31 -0000 Eric Rescorla wrote: > > At Fri, 27 Nov 2009 16:27:03 +0100 (MET), > Martin Rex wrote: > > > > That problem can be trivially fixed. > > > > We just memorize the non-encrypted Client.Finished and Server.Finished > > handshake messages in full, rather then just the contained verify_data. > > Woah, that's scary.... > > We're going to take the exact messages that previously appeared on the > wire and inject them into the handshake hashes in order to *reduce* > ambiguity in the hash input stream? I mean, maybe that's OK, but it > sure isn't obviously OK. What we would be doing is limiting the ambiguity with something arbitrary to the ambiguity with a very well-defined handshake message (actually, two of them). -Martin From uri@ll.mit.edu Fri Nov 27 08:40:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851733A6928 for ; Fri, 27 Nov 2009 08:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d12V7gmZIWx9 for ; Fri, 27 Nov 2009 08:40:04 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id A8AF73A685D for ; Fri, 27 Nov 2009 08:40:04 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nARGdvQg001567 for ; Fri, 27 Nov 2009 11:39:57 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAA4waqFa; Fri Nov 27 11:36:13 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Fri, 27 Nov 2009 11:36:13 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Fri, 27 Nov 2009 11:36:12 -0500 Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpvfQRMuompHuoVRZW4RYNHuYaOcwAArbKg Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F49@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:40:05 -0000 Ikp1c3Qgc2F5IG5vISINCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiB0 bHMtYm91bmNlc0BpZXRmLm9yZyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogbXJleEBzYXAu Y29tIDxtcmV4QHNhcC5jb20+DQpDYzogdGxzQGlldGYub3JnIDx0bHNAaWV0Zi5vcmc+DQpTZW50 OiBGcmkgTm92IDI3IDExOjE3OjI0IDIwMDkKU3ViamVjdDogUmU6IFtUTFNdIFZlcmlmeSBkYXRh IGluIHRoZSBSSSBleHRlbnNpb24/DQoNCkF0IEZyaSwgMjcgTm92IDIwMDkgMTY6Mjc6MDMgKzAx MDAgKE1FVCksDQpNYXJ0aW4gUmV4IHdyb3RlOg0KPiANCj4gRXJpYyBSZXNjb3JsYSB3cm90ZToN Cj4gPiANCj4gPiBJIGFsc28gc2hhcmUgRGF2aWQgSG9wd29vZCdzIGNvbmNlcm4gYWJvdXQgYW1i aWd1aXR5IGluIHRoZSBoYW5kc2hha2UNCj4gPiBoYXNoZXMgc3RyZWFtIGNyZWF0ZWQgYnkgaGF2 aW5nIGRhdGEgd2hpY2ggaXMgbm90IHByb3Blcmx5IGZvcm1hdHRlZA0KPiA+IGluamVjdGVkIGlu dG8gdGhlIGhhc2gNCj4gPiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rs cy9jdXJyZW50L21zZzA0ODU3Lmh0bWwpLA0KPiA+IHNvIEkgZG9uJ3QgdGhpbmsgdGhlIHBhcnRp Y3VsYXIgYXBwcm9hY2ggaW4gTWFydGluJ3MgZHJhZnQgaXMNCj4gPiByZWFsbHkgc2F0aXNmYWN0 b3J5Lg0KPiANCj4gVGhhdCBwcm9ibGVtIGNhbiBiZSB0cml2aWFsbHkgZml4ZWQuDQo+IA0KPiBX ZSBqdXN0IG1lbW9yaXplIHRoZSBub24tZW5jcnlwdGVkIENsaWVudC5GaW5pc2hlZCBhbmQgU2Vy dmVyLkZpbmlzaGVkDQo+IGhhbmRzaGFrZSBtZXNzYWdlcyBpbiBmdWxsLCByYXRoZXIgdGhlbiBq dXN0IHRoZSBjb250YWluZWQgdmVyaWZ5X2RhdGEuDQoNCldvYWgsIHRoYXQncyBzY2FyeS4uLi4N Cg0KV2UncmUgZ29pbmcgdG8gdGFrZSB0aGUgZXhhY3QgbWVzc2FnZXMgdGhhdCBwcmV2aW91c2x5 IGFwcGVhcmVkIG9uIHRoZQ0Kd2lyZSBhbmQgaW5qZWN0IHRoZW0gaW50byB0aGUgaGFuZHNoYWtl IGhhc2hlcyBpbiBvcmRlciB0byAqcmVkdWNlKg0KYW1iaWd1aXR5IGluIHRoZSBoYXNoIGlucHV0 IHN0cmVhbT8gSSBtZWFuLCBtYXliZSB0aGF0J3MgT0ssIGJ1dCBpdA0Kc3VyZSBpc24ndCBvYnZp b3VzbHkgT0suDQoNCi1Fa3INCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From mrex@sap.com Fri Nov 27 09:11:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7DE3A6A42 for ; Fri, 27 Nov 2009 09:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 HIADj1b1+FiU for ; Fri, 27 Nov 2009 09:11:04 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 636993A6A2C for ; Fri, 27 Nov 2009 09:11:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARHAu3l007908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 18:10:56 +0100 (MET) From: Martin Rex Message-Id: <200911271710.nARHAsu8008272@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 27 Nov 2009 18:10:54 +0100 (MET) In-Reply-To: <20091127161724.3DF546C37C8@kilo.networkresonance.com> from "Eric Rescorla" at Nov 27, 9 08:17:24 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 17:11:07 -0000 Eric Rescorla wrote: > > Woah, that's scary.... > > We're going to take the exact messages that previously appeared on the > wire and inject them into the handshake hashes in order to *reduce* > ambiguity in the hash input stream? I mean, maybe that's OK, but it > sure isn't obviously OK. A possible solution to avoid the ambiguity might look like the following: -Martin ssl/s3_srvr.c:ssl3_send_server_hello() ret = ssl3_do_write(s,SSL3_RT_HANDSHAKE); if ( ret>0 ) { if ( s->s3->peer_is_updated || 0==s->s3->allow_old_renego ) { if ( s->s3->renegotiate ) { /* add previous Client.Finished to handshake msg hash */ ssl3_finish_mac(s,s->s3->peer_finished, s->s3->peer_finished_len); /* add previous Server.Finished to handshake msg hash */ ssl3_finish_mac(s,s->s3->finished, s->s3->finished_len); } else { /* add initial handshake msg hash differentiator */ ssl3_finished_mac(s,"\x01\x55\xAA\x55", 4 ); } } else { if ( s->s3->renegotiate ) { /* Servers SHOULD NOT offer old renegotiation anymore */ /* if (0==(s->options&SSL_OP_ALLOW_INSECURE_RENEGOTIATE))*/ ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_HANDSHAKE_FAILURE); ret = -1; } } } return(ret); From Pasi.Eronen@nokia.com Fri Nov 27 09:31:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDF93A6978 for ; Fri, 27 Nov 2009 09:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Ilf1j1i3t5+j for ; Fri, 27 Nov 2009 09:31:15 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 2513F3A67D1 for ; Fri, 27 Nov 2009 09:31:14 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nARHV549022503; Fri, 27 Nov 2009 19:31:05 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 19:31:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 19:30:57 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 27 Nov 2009 18:30:45 +0100 From: To: Date: Fri, 27 Nov 2009 18:30:43 +0100 Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: Acpvbi1Bd+KS95omSUGhHzQ5I95GUQAGAQHA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3118C344@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3113EEDC@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 27, 9 03:09:58 pm <200911271425.nAREP95E028727@fs4113.wdf.sap.corp> In-Reply-To: <200911271425.nAREP95E028727@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2009 17:30:57.0900 (UTC) FILETIME=[6168B2C0:01CA6F87] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 17:31:16 -0000 Martin Rex wrote: > > For simplicity, the current draft is already very simple, and IMHO > > it's not clear that continuing to tweak it has a positive return > > on investment, considering it delays the publication. >=20 > Not really. >=20 > I ask this before: what should the original designers of the SSLv3 > renegotiation have done from the beginning to make it secure. > Invent TLS extensions and then a TLS extension RI is definitely > _not_ the answer. They would have fixed the handshake message hash > from the beginning. I think "what would the SSLv3 designers have done" (almost 15 years ago) and "what should we today" are two completely different questions, which may have completely different answers. > The "dirty ugly" signaling is a patch for a "dirty ugly" security > problem in "dirty old" implementations of a "dirty old" protocol. > We need it to distinguish old from updated implementations and for > supporting interop with old -- otherwise we could just change both > handshake algorithms (like including different finished labels) and > make the fix entirely without on-the-wire changes, no signaling, but > also no interop with the installed base. >=20 > > About future versions of TLS, IMHO it's quite difficult to predict > > which would be most compatible. What if, e.g., the next version of > > TLS decides that sending certificates in the clear wasn't that > > great idea, and nowadays we can afford to do Diffie-Hellman before > > doing any authentication? This could completely change all the > > handshake messages after ClientHello, and the current > > functionality of "Finished" could be done in quite different way.. >=20 > If it does not retain (Extended)ServerHello, then it will actually > kill a lot of the existing SSL/TLS protocol features -- and reliably > kill TLS extension RI with it. >=20 > The handshake message hash is one of the basic concepts of the > SSL/TLS protocol. If that is changed, then you basically have > none of the original protocol left. >=20 > Therefore directly feeding into the handshake message hash is > the more conservative and forward compatible approach. We haven't had *any* discussions in the WG about what the next version of TLS could or should or might change, so I don't think we can have even any "informed guesses" about it. So while your proposal may be conservative, IMHO claiming it's "forward compatible" cannot be based on anything except totally wild guesses... (and other people making totally wild guesses about the topic might reasonably guess very differently) Best regards, Pasi (not wearing any hats) From mrex@sap.com Fri Nov 27 10:05:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AEA03A68D8 for ; Fri, 27 Nov 2009 10:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 8-Jqf4ghOrWO for ; Fri, 27 Nov 2009 10:05:04 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2D7423A684D for ; Fri, 27 Nov 2009 10:05:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARI4vfd015893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 19:04:57 +0100 (MET) From: Martin Rex Message-Id: <200911271804.nARI4u3v011522@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Fri, 27 Nov 2009 19:04:56 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118C344@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 27, 9 06:30:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 18:05:05 -0000 Pasi.Eronen@nokia.com wrote: > > Martin Rex wrote: > > > > For simplicity, the current draft is already very simple, and IMHO > > > it's not clear that continuing to tweak it has a positive return > > > on investment, considering it delays the publication. > > > > Not really. > > > > I ask this before: what should the original designers of the SSLv3 > > renegotiation have done from the beginning to make it secure. > > Invent TLS extensions and then a TLS extension RI is definitely > > _not_ the answer. They would have fixed the handshake message hash > > from the beginning. > > I think "what would the SSLv3 designers have done" (almost 15 years > ago) and "what should we today" are two completely different > questions, which may have completely different answers. If we were discussing a new feature for TLSv1.2 or TLSv1.3 only, I would agree. But we're actually going back to code that is 10 years or more and want that fixed as well. So we need to pay a little more attention to the perils of poor souls from the dirty old cruft department than to the dreams of the nerds from the fancy new features department. -Martin From ekr@networkresonance.com Fri Nov 27 11:26:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887BA3A6964 for ; Fri, 27 Nov 2009 11:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.066 X-Spam-Level: X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGCqclI0oR8f for ; Fri, 27 Nov 2009 11:26:43 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id BFE873A68F2 for ; Fri, 27 Nov 2009 11:26:43 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id BF0EF6C37E9; Fri, 27 Nov 2009 11:27:23 -0800 (PST) Date: Fri, 27 Nov 2009 11:27:23 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200911271634.nARGYKm1006390@fs4113.wdf.sap.corp> References: <20091127161724.3DF546C37C8@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091127192723.BF0EF6C37E9@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 19:26:44 -0000 At Fri, 27 Nov 2009 17:34:20 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > At Fri, 27 Nov 2009 16:27:03 +0100 (MET), > > Martin Rex wrote: > > > > > > That problem can be trivially fixed. > > > > > > We just memorize the non-encrypted Client.Finished and Server.Finished > > > handshake messages in full, rather then just the contained verify_data. > > > > Woah, that's scary.... > > > > We're going to take the exact messages that previously appeared on the > > wire and inject them into the handshake hashes in order to *reduce* > > ambiguity in the hash input stream? I mean, maybe that's OK, but it > > sure isn't obviously OK. > > What we would be doing is limiting the ambiguity with something > arbitrary to the ambiguity with a very well-defined handshake > message (actually, two of them). Hmm... Thinking about this some more, consider the case of a client which (improperly) ignores handshake messages which come out of sequence, but still hashes them into handshake hashes. In the simple attack where the server thinks there is a rehandshake and the client thinks it is the initial handshake, what if the attacker between the client and the server injects the replayed Client.Finished and Server.Finished messages into the message stream going towards the client. The client would then ignore but hash the messages with the result that the data hashed by the client being the is the same as the data being hashed by the server and the attack succeeds. Am I missing something here? Obviously, one could just say that the client is misbehaving here and so this doesn't matter (though I would note that others have expressed concerns about what happens with implementation errors, and this is only requires an error by one side, not both). However, I think it's illustrative that we need to be pretty careful about introducing ambiguity between messages that are on the wire and those that are merely hashed. -Ekr From mrex@sap.com Fri Nov 27 12:02:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849663A6851 for ; Fri, 27 Nov 2009 12:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 HKNj2Xzn417L for ; Fri, 27 Nov 2009 12:02:58 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6FEA33A699E for ; Fri, 27 Nov 2009 12:02:58 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARK2o8b006769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 21:02:50 +0100 (MET) From: Martin Rex Message-Id: <200911272002.nARK2m3I018999@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 27 Nov 2009 21:02:48 +0100 (MET) In-Reply-To: <20091127192723.BF0EF6C37E9@kilo.networkresonance.com> from "Eric Rescorla" at Nov 27, 9 11:27:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 20:02:59 -0000 Eric Rescorla wrote: > > > > What we would be doing is limiting the ambiguity with something > > arbitrary to the ambiguity with a very well-defined handshake > > message (actually, two of them). > > Hmm... > > Thinking about this some more, consider the case of a client which > (improperly) ignores handshake messages which come out of sequence, > but still hashes them into handshake hashes. I did consider that, see the solution here: http://www.ietf.org/mail-archive/web/tls/current/msg04920.html this will make the initial and renegotiation handshake message hash reliably distinct. And btw. when a TLS peer ignores two incorrect finished messages on a connection, then there are a lot more things to worry about. Those are completely unlikely to get the TLS extension RI right. -Martin From Pasi.Eronen@nokia.com Fri Nov 27 12:11:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D2C3A68AF for ; Fri, 27 Nov 2009 12:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 eF5C3UXFb2iP for ; Fri, 27 Nov 2009 12:11:20 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7FB413A699E for ; Fri, 27 Nov 2009 12:11:17 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nARKB8BS008614; Fri, 27 Nov 2009 22:11:08 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 22:11:03 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 22:11:03 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 22:10:58 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 27 Nov 2009 21:10:57 +0100 From: To: Date: Fri, 27 Nov 2009 21:10:55 +0100 Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpvjCagBvHY2IhmRA+hEL1HdO2bDAAEP47g Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3118C377@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3118C344@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 27, 9 06:30:43 pm <200911271804.nARI4u3v011522@fs4113.wdf.sap.corp> In-Reply-To: <200911271804.nARI4u3v011522@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2009 20:10:58.0475 (UTC) FILETIME=[BBCC2FB0:01CA6F9D] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 20:11:28 -0000 Martin Rex wrote: > > I think "what would the SSLv3 designers have done" (almost 15 years > > ago) and "what should we today" are two completely different > > questions, which may have completely different answers. >=20 > If we were discussing a new feature for TLSv1.2 or TLSv1.3 only, I > would agree. >=20 > But we're actually going back to code that is 10 years or more and > want that fixed as well. So we need to pay a little more attention > to the perils of poor souls from the dirty old cruft department than > to the dreams of the nerds from the fancy new features department. I fully agree that deployment (even with old implementations) needs to be taken into account -- otherwise we'd be ignoring reality. But *none* of the proposals made so far would be the solution SSLv3 designers would have picked, had someone pointed out this problem before implementations had shipped. For starters, they would not have needed signalling (in either direction), which is one of the main issues we're facing today... Best regards, Pasi (not wearing any hats) From SRS0=3D4J=HP=acm.org=bmoeller@srs.kundenserver.de Fri Nov 27 13:46:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB723A68C4 for ; Fri, 27 Nov 2009 13:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 vTTR8H435gJW for ; Fri, 27 Nov 2009 13:46:31 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 03E953A6893 for ; Fri, 27 Nov 2009 13:46:30 -0800 (PST) Received: from [10.1.124.144] ([74.125.121.49]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M1CM0-1O7C8R2JMu-00tHEU; Fri, 27 Nov 2009 22:46:21 +0100 From: Bodo Moeller To: Stefan Santesson In-Reply-To: References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Nov 2009 22:46:17 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+PWTkYYRjJ+iOLW3PDk9v5tyatOEI/0BkXqel lrrtrkeqZhpBHXPrrE+nLHXDwNWhb4QDziCW3AaNFNupPlovcT 4FHZYWhqtr5vixjkZFO+A== Cc: tls@ietf.org Subject: Re: [TLS] Avoiding first use of RI in ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 22:05:14 -0000 On Nov 26, 2009, at 6:34 PM, Stefan Santesson wrote: > Reading the draft I realize I misunderstood one aspect. > > I don't understand the benefit from having different signaling in the > initial handshakes and renegotiation handshakes. > > Especially since I think it is better security design to not send > the verify > data from previous handshakes. You didn't misunderstand this here -- Eric focussed on the signaling issue here, saying the issue of whether the verify_data should be included in extensions is a separate one. (Which, I guess, is also why you changed the "Subject" line for further discussion of that topic :-) ) Anyway, I'm really writing now to confirm that the signaling approach as used in draft-ietf-tls-renegotiation-01.txt looks fine to me. Bodo From SRS0=3D4J=HP=acm.org=bmoeller@srs.kundenserver.de Fri Nov 27 14:04:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CCC3A695D for ; Fri, 27 Nov 2009 14:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 VH5sm4DC7J6z for ; Fri, 27 Nov 2009 14:04:10 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id B58DD3A68A9 for ; Fri, 27 Nov 2009 14:04:09 -0800 (PST) Received: from [10.1.124.144] ([74.125.121.49]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MHtl3-1NHhon2IFp-003a8k; Fri, 27 Nov 2009 23:03:57 +0100 From: Bodo Moeller To: Eric Rescorla In-Reply-To: <20091127192723.BF0EF6C37E9@kilo.networkresonance.com> References: <20091127161724.3DF546C37C8@kilo.networkresonance.com> <20091127192723.BF0EF6C37E9@kilo.networkresonance.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Nov 2009 23:03:55 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+XgHtDI/Rpzvz8+tgO082keImMxnrNmxHAnAd PI0eNIW3LbU2Ysrfc/uABIgG9SZpNHrDnSUeQXafuT0T0yHUqJ MDJebcpLtqQ/elXH2IUhA== Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 22:05:15 -0000 On Nov 27, 2009, at 8:27 PM, Eric Rescorla wrote: > Thinking about this some more, consider the case of a client which > (improperly) ignores handshake messages which come out of sequence, > but still hashes them into handshake hashes. > > In the simple attack where the server thinks there is a rehandshake > and the client thinks it is the initial handshake, what if the > attacker between the client and the server injects the > replayed Client.Finished and Server.Finished messages into the message > stream going towards the client. The client would then ignore but hash > the messages with the result that the data hashed by the client being > the is the same as the data being hashed by the server and the attack > succeeds. Am I missing something here? > > Obviously, one could just say that the client is misbehaving here > and so this doesn't matter (though I would note that others have > expressed > concerns about what happens with implementation errors, and this is > only > requires an error by one side, not both). However, I think it's > illustrative > that we need to be pretty careful about introducing ambiguity between > messages that are on the wire and those that are merely hashed. While this looks a little far-fetched to me, many security issues found in practice seem far-fetched if you don't know that they're real -- what you're writing here is enough to convince me that if there's one canonical way to solve the security problem, it's with including explicit verify_data in renegotiation handshake hello extensions. The one thing I don't agree with in draft-ietf-tls- renegotiation-01.txt regarding the extensions is having the ServerHello concatenate the client and server verify_data. That's pointless given that the client sends its one verify_data in its extension -- the server should only send its own verify_data. I have one more concern with draft-ietf-tls-renegotiation-01.txt: The ID says "By default, TLS implementations conforming to this document MUST verify that once the peer has been identified and authenticated within the TLS handshake, the identity does not change on subsequent renegotiations. For certificate based cipher suites, this means bitwise equality of the end-entity certificate. If the other end attempts to authenticate with a different identity, the renegotiation MUST fail. If the server_name extension is used, it MUST NOT change when doing renegotiation." It makes sense to require this when a party conforming to this specification falls back to compatible mode, when it has determined that according to the handshake the peer does not conform to the specification. However, if the client and server *both* confirm to the specification and thus have secure channel binding across renegotiations, there's no point in forbidding "identity" changes (which may not be really identity changes, but other create and yet valid uses of TLS renegotiation -- for example, consider a server that uses a particular ciphersuite [requiring a special certificate] only with authenticated clients [and thus in a renegotiation handshake], to name just one example). There's no 1-to-1 mapping between certificate and "identities" -- at best a certificate is a particular "name", but a single entity can legitimately use multiple names. Bodo From Pasi.Eronen@nokia.com Fri Nov 27 14:26:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391B73A6957 for ; Fri, 27 Nov 2009 14:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 uyivsvssSEsU for ; Fri, 27 Nov 2009 14:26:46 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1E8C13A6ABD for ; Fri, 27 Nov 2009 14:26:45 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nARMQaSs015489 for ; Sat, 28 Nov 2009 00:26:36 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 28 Nov 2009 00:26:35 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 28 Nov 2009 00:26:36 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 27 Nov 2009 23:26:35 +0100 From: To: Date: Fri, 27 Nov 2009 23:26:34 +0100 Thread-Topic: Next steps for draft-ietf-tls-renegotiation Thread-Index: AcpvsK00o1AiVoleTQuKgrA4F9s+kw== Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2009 22:26:36.0292 (UTC) FILETIME=[AE508440:01CA6FB0] X-Nokia-AV: Clean Subject: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 22:26:47 -0000 I have asked the secretariat to start IETF Last Call for draft-rescorla-tls-renegotiation-01. I've gone through the list archives for the past month, and it seems a large majority of the WG members support the overall approach in this draft (with a small, but very vocal, minority preferring a totally extension-less approach to signalling). I think the users of TLS at this point are served better by a timely solution that works and is "good enough", rather than continuing the tweaking. Especially since a large majority of the WG is OK with the signalling approach in the current draft, it looks like continuing to tweak the non-signalling parts is not going to provide any significant additional benefits to the users of TLS. The exact text in the -01 draft is still a bit rough (a number of places could probably benefit from clarifications, and perhaps some implementation advice, too), and I hope we can continue improving it during the last call (for example, Martin's draft has lot of well-written text we should probably consider including here).=20 Best regards, Pasi IETF Security Area Director From SRS0=3D4J=HP=acm.org=bmoeller@srs.kundenserver.de Fri Nov 27 14:36:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9BB3A6AC2 for ; Fri, 27 Nov 2009 14:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 K0EQSanV75wK for ; Fri, 27 Nov 2009 14:36:55 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 7A3BE3A6ABD for ; Fri, 27 Nov 2009 14:36:55 -0800 (PST) Received: from bmoeller-macbookpro.fritz.box (77-57-208-242.dclient.hispeed.ch [77.57.208.242]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MK5c9-1NFWTQ2pU5-001OME; Fri, 27 Nov 2009 23:36:46 +0100 From: Bodo Moeller To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F310FE976@NOK-EUMSG-01.mgdnok.nokia.com> References: <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com> <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> <4B0D5EF3.3020905@extendedsubset.com> <20091125165522.A2CDA6C3173@kilo.networkresonance.com> <808FD6E27AD4884E94820BC333B2DB774F310FE976@NOK-EUMSG-01.mgdnok.nokia.com> Message-Id: <79D75A57-260E-4ECC-90FF-9EB3B9B99F66@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Nov 2009 23:36:44 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX18F3lN2LdAOlwQ4TSsCuDImzyCejyKsUgTo7ZY 88azibfMRnSx3LDwLz8a+E2ckLXc0K4oTNHcG7L5I4YOlCSULT f3Y00G0Vfgbu4tCjsnEaw== Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 22:36:56 -0000 On Nov 25, 2009, at 9:02 PM, wrote: > While the RI extension fixes the man-in-the-middle problem, it doesn't > remove the problems when there is no man-in-the-middle, just the two > endpoints (either of whom could be potentially malicious). Why do you think so? If an RI-secured renegotiation shows a new certificate, this confirms that the same party is using those two certificates. How could an additional (potentially malicious) party join the conversation? Bodo From SRS0=3D4J=HP=acm.org=bmoeller@srs.kundenserver.de Fri Nov 27 15:47:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345003A68CF for ; Fri, 27 Nov 2009 15:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 6gYmFVgtCrRI for ; Fri, 27 Nov 2009 15:47:05 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 45D843A682D for ; Fri, 27 Nov 2009 15:47:04 -0800 (PST) Received: from bmoeller-macbookpro.fritz.box (77-57-208-242.dclient.hispeed.ch [77.57.208.242]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LnFtp-1NmhWp0GUP-00hJoY; Sat, 28 Nov 2009 00:46:58 +0100 From: Bodo Moeller To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 28 Nov 2009 00:46:57 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+VU1JfQxaxdjCrD9JvjD6RkqQs9djEfUPR1IB J0PcrISsJGoKCNYpODkjtysl57Bzj2X7GPvElwinQTk43/vXg7 xbu2rF3JQwsnRlxf/frSA== Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 23:47:06 -0000 On Nov 27, 2009, at 11:26 PM, wrote: > > > I have asked the secretariat to start IETF Last Call for > draft-rescorla-tls-renegotiation-01. No, you haven't -- or so I hope: You must have asked about draft-ietf- tls-renegotiation-01. Bodo From stefan@aaa-sec.com Fri Nov 27 16:06:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EB53A681E for ; Fri, 27 Nov 2009 16:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDTF5Ssa5hYI for ; Fri, 27 Nov 2009 16:06:43 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 2824D3A67AC for ; Fri, 27 Nov 2009 16:06:42 -0800 (PST) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2B71228E25F for ; Sat, 28 Nov 2009 01:06:44 +0100 (CET) Received: (qmail 79819 invoked from network); 28 Nov 2009 00:06:34 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Nov 2009 00:06:34 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sat, 28 Nov 2009 01:06:33 +0100 From: Stefan Santesson To: , Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: AcpvsK00o1AiVoleTQuKgrA4F9s+kwADfdv9 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 00:06:44 -0000 Pasi, For the record I just need to say that I strongly disagree with this decision. We have two solutions on the table and the essence of them has been concluded during the very last few days. I would say that the support for either of the two approaches has been quite even lately. It surprises me that we don't even have time to seriously ask the WG members what approach they prefer. I can just hope this in the end will turn out to be of service to the community and that all implementers get this right. I would really hate for us to conclude that we patched one vulnerable security design with another due to implementer shortcomings, or that a large part of the community turned off a useful TLS feature. It was interesting to have the discussion. /Stefan On 09-11-27 11:26 PM, "Pasi.Eronen@nokia.com" wrote: > > > I have asked the secretariat to start IETF Last Call for > draft-rescorla-tls-renegotiation-01. > > I've gone through the list archives for the past month, and it seems a > large majority of the WG members support the overall approach in this > draft (with a small, but very vocal, minority preferring a totally > extension-less approach to signalling). > > I think the users of TLS at this point are served better by a timely > solution that works and is "good enough", rather than continuing the > tweaking. Especially since a large majority of the WG is OK with the > signalling approach in the current draft, it looks like continuing to > tweak the non-signalling parts is not going to provide any significant > additional benefits to the users of TLS. > > The exact text in the -01 draft is still a bit rough (a number of > places could probably benefit from clarifications, and perhaps some > implementation advice, too), and I hope we can continue improving it > during the last call (for example, Martin's draft has lot of > well-written text we should probably consider including here). > > Best regards, > Pasi > IETF Security Area Director > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mike-list@pobox.com Fri Nov 27 16:31:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0E03A682F for ; Fri, 27 Nov 2009 16:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 4A5-nwMbHhQ9 for ; Fri, 27 Nov 2009 16:31:55 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id D9CE53A682D for ; Fri, 27 Nov 2009 16:31:54 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D264583A24 for ; Fri, 27 Nov 2009 19:31:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=oxWyQAl7/r+0 7qhaeZ4Y+ORlBrY=; b=QEy4ElFo6qSX3QIpiA2nG9NWaqGECcqQolYhI2wPwcnV CQ72r2YrdiY19OXge0g3lGBGUeOVKxcEyyjlzBGdKXlK6aKS7bnlA3TW4/v8qkJQ u4YXzJSht3AyrN56BXpwLMIP5JdN6KjfSopHdi+xkNw7Yxnpd5vV1toiESIi0XI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=nhKwWb PZBjFI+P+iTFyHS3dpmv5iocmv6JakW2hOTZVPelqsgX5QNOqE4pErrgoKNnF7Yz bAxlW6EQZum0FdJZvlYEIaHtPcJVn2O2eTH4zJSTgrjyqCCmcQD0m+qPNJX9Tv5a CDzqBYRCVGz1l/bYMbnpjNYhB4m6idQrmV0gQ= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D01E083A23 for ; Fri, 27 Nov 2009 19:31:46 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 62D8783A22 for ; Fri, 27 Nov 2009 19:31:46 -0500 (EST) Message-ID: <4B106FCB.4070007@pobox.com> Date: Fri, 27 Nov 2009 16:33:15 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <20091127161724.3DF546C37C8@kilo.networkresonance.com> <20091127192723.BF0EF6C37E9@kilo.networkresonance.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 693344C6-DBB5-11DE-B51D-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 00:31:56 -0000 Bodo Moeller wrote: > > I have one more concern with draft-ietf-tls-renegotiation-01.txt: > > The ID says > "By default, TLS implementations conforming to this document MUST verify > that once the peer has been identified and authenticated within the TLS > handshake, the identity does not change on subsequent renegotiations. > For certificate based cipher suites, this means bitwise equality of the > end-entity certificate. If the other end attempts to authenticate with a > different identity, the renegotiation MUST fail. If the server_name > extension is used, it MUST NOT change when doing renegotiation." > It makes sense to require this when a party conforming to this > specification falls back to compatible mode, when it has determined that > according to the handshake the peer does not conform to the > specification. However, if the client and server *both* confirm to the > specification and thus have secure channel binding across > renegotiations, there's no point in forbidding "identity" changes (which > may not be really identity changes, but other create and yet valid uses > of TLS renegotiation -- for example, consider a server that uses a > particular ciphersuite [requiring a special certificate] only with > authenticated clients [and thus in a renegotiation handshake], to name > just one example). There's no 1-to-1 mapping between certificate and > "identities" -- at best a certificate is a particular "name", but a > single entity can legitimately use multiple names. In addition, a TLS 1.2 server may have two certificates for the *same* name; one signed with SHA-1 and another signed with SHA-256. Mike From djhopwood@googlemail.com Fri Nov 27 17:09:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197F43A6852 for ; Fri, 27 Nov 2009 17:09:16 -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 8B3rB1Qvm86Q for ; Fri, 27 Nov 2009 17:09:15 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id C3A5B3A681E for ; Fri, 27 Nov 2009 17:09:10 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so512509eyf.51 for ; Fri, 27 Nov 2009 17:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=kNxajC7uYFB05cYurMht7SuXXMgi896PcQRprn7/Y/Y=; b=moDbiO7u8Fq3QezVnJKO3s+nb9sBdmkxYSN+0BPIQGG+Nen45UyJKLyV9g1f93UqzY My9FmaogDk0HCY+muiyxYs6EhK5qKABnJ/alwhNBYzS3dvDRIGFy9Bn+gYzrznm9XhX9 Vh+4WyVLDsNMTLhswBRvdArWnaeXSq6my0jcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=KC0yYlDszl8XbU/4awUrU4PnjgNyzeTLPD0XUPge7KSfpqBDYlQ9at12M3BBsRP5MT spN00yJL8KqKoLaPkrn5lHemVzArWfQKzOptduQkOVpTF+ExN1JW/Q/OaoAJHlC+ITKt QrWI75YK7TgiM1b0UMDNzHb+p2YzTE+ajno5k= Received: by 10.216.86.200 with SMTP id w50mr507919wee.173.1259370539869; Fri, 27 Nov 2009 17:08:59 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id t2sm5085896gve.9.2009.11.27.17.08.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 17:08:58 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B107823.1040804@jacaranda.org> Date: Sat, 28 Nov 2009 01:08:51 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <200911261801.nAQI1nCd015456@fs4113.wdf.sap.corp> In-Reply-To: <200911261801.nAQI1nCd015456@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBA3521F98BB40D3129474ADE" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 01:09:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBA3521F98BB40D3129474ADE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I now agree that we should change handshake_messages, but I disagree with something else you say below: Martin Rex wrote: > You'll have to keep double the state around in order to be able > to calculate the Server.Finished of the Renegotiation, and > then transfer shift the oldest verify_data out after Server.Finished. >=20 > It's more code, it doesn't address the CertificateVerify at all > and to interop-test this reliably, you will need to perform > at least two rengotiations on a communication channel to be > sure that the shifting of the Finished messages works correctly. This test (of a double-renegotiation) certainly should be done anyway. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigBA3521F98BB40D3129474ADE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksQeDAACgkQWUc8YzyzqAd8cwD+MSS5dFEixy+QTrXG77tD97ox yOlcxGgfU0vag0mFxNQBAJye+LM9s/GbguoXEBjmvn4uwr9S5NWWQiabrZxdm8zv =THRE -----END PGP SIGNATURE----- --------------enigBA3521F98BB40D3129474ADE-- From djhopwood@googlemail.com Fri Nov 27 17:45:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7CF3A6819 for ; Fri, 27 Nov 2009 17:45:16 -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 erNpkJwY1EZy for ; Fri, 27 Nov 2009 17:45:15 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 902393A680E for ; Fri, 27 Nov 2009 17:45:15 -0800 (PST) Received: by ewy6 with SMTP id 6so1146394ewy.29 for ; Fri, 27 Nov 2009 17:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=muyv0J9gdUbJhEp6+k6Te9cvOouhwDJLQK/1u5DiCoA=; b=BjgcXEtdHm6WIHYICnFD/AbZyjxCGawVFgaLePY1m1QN7Ryi0Cmq6BpTUOADYucNik snm3XiPQygUk4NeA77H7nT4uttCrET4bw8+agKunlTOmuPnvQ6/38p9ltaU7ao2jfaz1 1b2aAg+x45g6iUrbXAtXf9UVY5FgTZkz7PWoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=frNM0MAKh+6JWaO/4wh44n1XKMqBX3V0IRg0ea591ES3TAtG5+hrll96p6w8c+nOeV mwiQlbJcgfanU10dnvVIfBeAX1XDvzrvsY4Kn/7lzn0n5ojP1olWXPzPv0SBfNdB6oOi fBDbPSotDKgntlniHsJWqivjXrqRQcTLPDy9M= Received: by 10.216.88.201 with SMTP id a51mr547456wef.154.1259372706122; Fri, 27 Nov 2009 17:45:06 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id u14sm5144842gvf.4.2009.11.27.17.45.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 17:45:05 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1080A7.3000401@jacaranda.org> Date: Sat, 28 Nov 2009 01:45:11 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig20540D97CAECC048962D54CC" Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 01:45:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig20540D97CAECC048962D54CC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pasi.Eronen@nokia.com wrote: > >=20 > I have asked the secretariat to start IETF Last Call for > draft-rescorla-tls-renegotiation-01. I believe that's premature. We are getting very close to a practical approach that has both security and interoperability advantages over draft-rescorla-tls-renegotiation-01. Starting Last Call now does not, IMHO, represent the concensus of the list. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig20540D97CAECC048962D54CC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksQgKgACgkQWUc8YzyzqAcH2QD5AStbmR9krXH9qJgSfnac+5NI yydno4vWqeuDqLRHnQ8A/3ZFRNjJ3y7aeEX1Jwqp0VMedtlGUYdPsZwZ9dQDzNnQ =m7AW -----END PGP SIGNATURE----- --------------enig20540D97CAECC048962D54CC-- From djhopwood@googlemail.com Fri Nov 27 19:50:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242003A684E for ; Fri, 27 Nov 2009 19:50: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 RFSq-md+uwxq for ; Fri, 27 Nov 2009 19:50:37 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id E30AC3A672E for ; Fri, 27 Nov 2009 19:50:36 -0800 (PST) Received: by ewy6 with SMTP id 6so1184826ewy.29 for ; Fri, 27 Nov 2009 19:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=5+fmhOA3jMd3qd/WA3voyFv47shZazYwi81N/5iSuX0=; b=ZLwLDNVVu8VRVYOHhxrClfaKpDFe0m8RjmU1EMVXA9UA2De27cxy8/2CUvAvdk3sNO YZq8lcGwBAmyT0eYPro7ZOowgfaKhdtwL/oDJSc2z5qruaDGPTiSjNcc32JW3d8UE/aU AKsL4PTPOY5T5mvtJA/4Y7W1dYbOb4twcLF9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=uVGMN4kLbOjPMl3zo1QPygl4iikBiVYF/BFsvJ3CPouBw6qwTzK5SChpn+umrEAgpK 81a2v3tAY0LteddZmJr3DGWwvo5jEL7mkAXMgO0jBiRB7tBg376fRsqtmEbFtnItFNgG +1Z3mFN7o2rzoFwyF0SFrNgcpT/HEV8RenTx8= Received: by 10.216.91.84 with SMTP id g62mr587455wef.216.1259380227608; Fri, 27 Nov 2009 19:50:27 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id t2sm5248083gve.24.2009.11.27.19.50.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 19:50:26 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B109DDE.3040200@jacaranda.org> Date: Sat, 28 Nov 2009 03:49:50 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig89149D38B779E53A639F334E" Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 03:50:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig89149D38B779E53A639F334E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [top-posting fixed] Stefan Santesson wrote: > On 09-11-26 8:01 PM, "David-Sarah Hopwood" > wrote: >=20 >> Stefan Santesson wrote: >>> Consequently, if we design an updated Finished calculation now, we ca= n keep >>> that in TLS 1.3 and just remove the signaling we now add for SSLv3 ->= TLS >>> 1.2. >> >> I really don't see any advantage in removing the signalling in TLS 1.3= =2E >> It doesn't simplify anything. >> >> For removing the signalling to work, we would have to specify in the >> *current* fix that: >> >> - sending a client version of {0x03, 0x04} or higher has the same >> meaning as sending the client->server signal. >> >> - negotiating {0x03, 0x04} or higher has the same meaning as sending >> the server->client signal. [...] > > If you fix the Finished message calculation, making it immune to the > renegotiation attack, and making it the standard Finished calculation f= or > 1.3.... Then why would you need to signal that you are using the standa= rd > Finished calculation? Suppose that a client is "strict", i.e. only wants to connect to patched servers. Since it doesn't know in advance that the server supports TLS 1.= 3, then it must send the c->s signal in order to find out whether the server= is patched. If the c->s signal is not sent, then the s->c signal can't be= sent either, so the client wouldn't know whether the server was patched, whenever TLS 1.2 or earlier is negotiated. This is important because an initial handshake by a patched client can correspond to a renegotiation at an unpatched server. So, it isn't sufficient that the client uses the updated Finished computation for renegotiations. Sending a client version >=3D TLS 1.3 can be treated as implying the c->s= signal, and negotiating TLS 1.3 can be treated as implying the s->c signa= l, but this won't eliminate any of the code that was handling signalling for= downrev versions. So this just adds code paths; it doesn't remove any. Of course, it is possible that at some point in the fairly distant future= , TLS 1.3 will be the *minimum* version that a given implementation will negotiate. At that point there would be a potential simplification -- but= it isn't at all clear that it outweighs the complication until then. (Note: I have a "Buxton index" of about 20 years, and I still don't think= this eventual simplification is worthwhile.) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig89149D38B779E53A639F334E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksQngcACgkQWUc8YzyzqAeHjgD+JJB0mHc9NSHb+4gDOa8jPwPs ehKHNFXtT9chhuyC5jAA/jZEvsJ5le9CUdnhlfq6E+jT2ukXWu3ia/8YhOwCvVig =9mXZ -----END PGP SIGNATURE----- --------------enig89149D38B779E53A639F334E-- From djhopwood@googlemail.com Fri Nov 27 20:05:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C60A3A67DF for ; Fri, 27 Nov 2009 20:05:45 -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 olqb6s8+kbxt for ; Fri, 27 Nov 2009 20:05:44 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 8FC293A67AF for ; Fri, 27 Nov 2009 20:05:43 -0800 (PST) Received: by ewy6 with SMTP id 6so1188822ewy.29 for ; Fri, 27 Nov 2009 20:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=TBTwM/9cDWguKmL9pQV7SSgS1+y5t6XUBc2t4xUcGbo=; b=XmUhYwgFUhjK+uZdCrR7wYXgh3uabFgBWp9lnNR8SMf7pr3Ll+p+SrFEetjF/nuA5h NbYUnM349tnAyjOOegmZsmJZYtH3h1SqxcCwEejOYS87iwU2a8R8Cqa6z/rGD4o2CGxq 7y+d+cy3DBy93FaXq0eQNRN54bNTHotyi326w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=CuzTqWvS4l4AXO34KThAVTwc27ukD7YGb5VgwgKavqK8OHuECB7mnJPiqNMeOYRCZ6 nrFkrMHWfmJ85BQGfhoJns9cTUjabnG/u2yCIaOkW07gieX8UOSdFbThQyC0vR6eQ3Or lnUBruUkxxSVcnxpEMi0vXoUDgjpLYGX8UHHA= Received: by 10.216.89.200 with SMTP id c50mr579138wef.137.1259381134071; Fri, 27 Nov 2009 20:05:34 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id j8sm5345477gvb.17.2009.11.27.20.05.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 20:05:33 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B10A184.4050107@jacaranda.org> Date: Sat, 28 Nov 2009 04:05:24 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0EF1AB.8050506@extendedsubset.com> <6A2B0911-C59D-4A11-94FA-713E46E89488@acm.org> In-Reply-To: <6A2B0911-C59D-4A11-94FA-713E46E89488@acm.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig670ACD35D790FBA4E1B30E39" Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 04:05:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig670ACD35D790FBA4E1B30E39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bodo Moeller wrote: > On Nov 26, 2009, at 10:22 PM, Marsh Ray wrote: >> Stefan Santesson wrote: >=20 >>> If you fix the Finished message calculation, making it immune to the >>> renegotiation attack, and making it the standard Finished calculation= >>> for >>> 1.3.... Then why would you need to signal that you are using the >>> standard >>> Finished calculation? >> >> So that clients and servers can be upgraded over a period of time >> without causing interoperability problems. >=20 > There are more than two ways how to treat signaling (how to signal that= > a new Finished computation should be used) with respect to future > protocol versions, i.e., TLS 1.3 and later: [numbering added] > 1. The specifications could mandate keeping the explicit signal even wi= th > TLS 1.3+. >=20 > 2. The specifications could require an explicit signal only for those T= LS > 1.3+ implementations that do offer backwards compatibility with earlier= > protocol versions (i.e., if the *negotiated* protocol version is TLS 1.= 3 > or later, that would imply that the new Finished computation should be > used). >=20 > 3. The specifications could require an explicit signal only for > implementations that don't announce TLS 1.3+ (i.e., if the *requested* > protocol version is TLS 1.3+, that would imply that the new Finished > computation should be used). >=20 > Stefan's proposal in the original message, it seems, was the third > variant. David's comment suggested that because of the complexity that= > comes with that variant, we should stick to the first one (and always > keep signaling). >=20 > That's not implied, though. The second variant makes a lot of sense to= > me -- it's just not something that the current specification would or > should have to say a final word on: that's best left to the TLS 1.3 > specification. No, we have to decide now. For approach 2 to work, *every* patched implementation must know that requesting TLS 1.3+ implies that a client is patched. For approach 3 to work, *every* patched implementation= must know that negotiating TLS 1.3+ implies that a server is patched. If we leave it until TLS 1.3 is specified, then there will exist implementations that don't know these things. Therefore, TLS 1.3+ clients= will have to send the c->s signal anyway, in case the server is one of those that doesn't know that a TLS 1.3+ request implies that it is OK to send the s->c signal. Similarly, TLS 1.3+ servers will have to send the s->c signal anyway, in case the client is one of those that doesn't know that negotiating TLS 1.3+ implies being patched. Thus, "not deciding" is effectively equivalent to deciding on approach 1.= --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig670ACD35D790FBA4E1B30E39 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksQoZMACgkQWUc8YzyzqAdF/gD/WY4TmZsLAvtTU81yLUrM2dPn hrp7bE6Da1pDuNGuo/EA/1ohteqqSpZe7D9qrpqMxyH2KMH2lLBnqWsEpEEPyZg+ =gvsH -----END PGP SIGNATURE----- --------------enig670ACD35D790FBA4E1B30E39-- From djhopwood@googlemail.com Fri Nov 27 20:25:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3153A672E for ; Fri, 27 Nov 2009 20:25:06 -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 eAMH8+sJ18bn for ; Fri, 27 Nov 2009 20:25:06 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 8FE5E3A67AF for ; Fri, 27 Nov 2009 20:25:05 -0800 (PST) Received: by ewy6 with SMTP id 6so1193747ewy.29 for ; Fri, 27 Nov 2009 20:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=nsncAC3O/ThLkT/za/gy+AU5DrDTgnHVHOg95H2Ocj8=; b=cIpVdpmfS6b7o+zQgsQ5b1t4mhsPgRtz3uPoV5W1Ms4xBM+ILDYErJm3ek84n3wBGO I9NM3+JSbKSmD4LG3yyzeMXH9v9E+zdqpXXhzVT4kZYQwqufVMdarMAisIvPMJx7wGwo DgLq8W18sugGbBuZQcRJD+IlsfMr/z5caLMXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=oneNsv2qTGDzujZXSN3+5aGpNx0ql4NzlA26u3LiDZRpZdSknZAvWVPCGIIxqnHhPo M5GUaY8xrfQLm6wuhVF01YqxHTmy9Yd1pOMt+67+DgLwKYd3ODKO41GoP3DToooP3jtt dnSJ4Mr82ph/T+ar7fmC4EtAz4FUYB20DllgY= Received: by 10.216.88.68 with SMTP id z46mr612283wee.27.1259382294140; Fri, 27 Nov 2009 20:24:54 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id i6sm5289041gve.16.2009.11.27.20.24.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 20:24:53 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B10A613.9070506@jacaranda.org> Date: Sat, 28 Nov 2009 04:24:51 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0EF1AB.8050506@extendedsubset.com> <6A2B0911-C59D-4A11-94FA-713E46E89488@acm.org> <4B10A184.4050107@jacaranda.org> In-Reply-To: <4B10A184.4050107@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB8B769F171DE3CE1AB4FCCCD" Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? [correction] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 04:25:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB8B769F171DE3CE1AB4FCCCD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Bodo Moeller wrote: >> On Nov 26, 2009, at 10:22 PM, Marsh Ray wrote: >>> Stefan Santesson wrote: >>>> If you fix the Finished message calculation, making it immune to the= >>>> renegotiation attack, and making it the standard Finished calculatio= n >>>> for >>>> 1.3.... Then why would you need to signal that you are using the >>>> standard >>>> Finished calculation? >>> So that clients and servers can be upgraded over a period of time >>> without causing interoperability problems. >> There are more than two ways how to treat signaling (how to signal tha= t >> a new Finished computation should be used) with respect to future >> protocol versions, i.e., TLS 1.3 and later: >=20 > [numbering added] >> 1. The specifications could mandate keeping the explicit signal even w= ith >> TLS 1.3+. >> >> 2. The specifications could require an explicit signal only for those = TLS >> 1.3+ implementations that do offer backwards compatibility with earlie= r >> protocol versions (i.e., if the *negotiated* protocol version is TLS 1= =2E3 >> or later, that would imply that the new Finished computation should be= >> used). >> >> 3. The specifications could require an explicit signal only for >> implementations that don't announce TLS 1.3+ (i.e., if the *requested*= >> protocol version is TLS 1.3+, that would imply that the new Finished >> computation should be used). >> >> Stefan's proposal in the original message, it seems, was the third >> variant. David's comment suggested that because of the complexity tha= t >> comes with that variant, we should stick to the first one (and always >> keep signaling). >> >> That's not implied, though. The second variant makes a lot of sense t= o >> me -- it's just not something that the current specification would or >> should have to say a final word on: that's best left to the TLS 1.3 >> specification. >=20 > No, we have to decide now. For approach 2 to work, *every* patched > implementation must know that requesting TLS 1.3+ implies that a > client is patched. For approach 3 to work, *every* patched implementati= on > must know that negotiating TLS 1.3+ implies that a server is patched. Correction: For approach 3 to work, *every* patched implementation must know that requesting TLS 1.3+ implies that a client is patched. > If we leave it until TLS 1.3 is specified, then there will exist > implementations that don't know these things. Therefore, TLS 1.3+ clien= ts > will have to send the c->s signal anyway, in case the server is one of > those that doesn't know that a TLS 1.3+ request implies that it is OK t= o > send the s->c signal. Similarly, TLS 1.3+ servers will have to send > the s->c signal anyway, in case the client is one of those that doesn't= > know that negotiating TLS 1.3+ implies being patched. The second part of this is wrong: TLS 1.3+ can be negotiated only if the client supports it, therefore it can be assumed that the client knows that negotiating TLS 1.3+ implies being patched. However, the first part was correct. So, "not deciding" is effectively equivalent to deciding against approach 3 (and also against a combination= of 2 and 3), while still leaving the choice between 1 and 2 open. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB8B769F171DE3CE1AB4FCCCD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksQphsACgkQWUc8YzyzqAfWgQEAn+aMUnyvEdAHjqKQdzo3xvx+ aYdpm7yHxSlj5uqOGNkBAJMc5tNW0qeKlbgkVNdFB3lu4suPLi9Tb22eMjG9utC7 =1EIP -----END PGP SIGNATURE----- --------------enigB8B769F171DE3CE1AB4FCCCD-- From djhopwood@googlemail.com Sat Nov 28 00:42:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF043A679C for ; Sat, 28 Nov 2009 00:42:03 -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 c-gnNQRYoFK7 for ; Sat, 28 Nov 2009 00:42:02 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 6C15D3A688A for ; Sat, 28 Nov 2009 00:42:02 -0800 (PST) Received: by ewy6 with SMTP id 6so1258775ewy.29 for ; Sat, 28 Nov 2009 00:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=0xZOZyZK6/pqnF14Lp5lamM+DtS9fq1BmczsT3cEFlQ=; b=WkNUJq1Kh4z8prxVmSq5CewPoXS5ZK6mva/qLjffmpNvS2p0X6Q3ZliU0nDWqP6CeV 7859rJuLAn5IhCkQ3J3yJ2jitwmqNCfFKSZiDMDmLTICk25cOI4/QI1eAXJyss/jvqnQ nOSKrHJlbfVZkExp2jZdFGU37pHWMDoAcOW6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=lPPaAmnLReTPx3vQHOrIRhmot1iNS6/geLWReReMWBE8CbuUpffEonHaAd+HBx8eZK iw6MAuqmG9O0WzWYczpXVvgH88UVi1xnuzD4kvoVWsIIW+zUcsiHtEJCzzT8pfPwO6w3 9TciC8vN1DtaTxB/UlVGRy1YmgZaJLmak8asw= Received: by 10.216.87.136 with SMTP id y8mr592725wee.70.1259397712875; Sat, 28 Nov 2009 00:41:52 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id u14sm5631520gvf.19.2009.11.28.00.41.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Nov 2009 00:41:18 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B10E225.4010501@jacaranda.org> Date: Sat, 28 Nov 2009 08:41:09 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> In-Reply-To: <20091127151113.BDEF16C3795@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD0A19434D5A1A2210F317B40" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 08:42:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0A19434D5A1A2210F317B40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > I also share [David-Sarah] Hopwood's concern about ambiguity in the han= dshake > hashes stream created by having data which is not properly formatted > injected into the hash > (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html), > so I don't think the particular approach in Martin's draft is > really satisfactory. That potential weakness can be avoided by encoding the data to be added into the hash as follows: struct { enum { fake_finished(20) } fake_handshake_type; enum { zero(0), (2^24-1) } fake_length; opaque previous_client_verify_data<12..255>; opaque previous_server_verify_data<12..255>; } PreviousVerifyData; This works because the bytes {20, 0, 0, 0} encode a zero-length Finished message, which if they actually appeared on the wire as a handshake message sent in either direction, would cause the recipient to abort the handshake. (This is similar to what Martin suggested in a recent post. Since any fake_length that is not a valid length for verify_data will work, we might as well use 0.) Note that for the receiver of the extra data to fail to abort the handshake in that case, it would have to make two independent errors, both violating 'MUST' requirements present since SSLv3: it would have to accept the empty Finished message out-of-order [*], *and* not check that the contents of that message is a correct verify_data hash. I'm completely satisfied that this approach solves the problem I was concerned about. > This isn't to say that one couldn't design a mechanism that didn't > carry the signaling data over the wire--one obviously could.=20 > However, when I look back over the 50 or so messages that were > sent to the list yesterday, a large fraction of them are various > tweaks on exactly how incorporate that data, which suggests to > me that this approach isn't at all easy to reason about. What matters is whether we have a solution that is easy to reason about (and to implement and specify) once it has been proposed, not how many posts to a mailing list were needed to get there. ---- [*] # The handshake protocol messages are presented in the order they must # be sent; sending handshake messages in an unexpected order results # in a fatal error. TLS 1.0 (RFC 2246) # The handshake protocol messages are presented below in the order they # must be sent; sending handshake messages in an unexpected order # results in a fatal error. Unneeded handshake messages can be omitted, # however. Note one exception to the ordering: the Certificate message # is used twice in the handshake (from server to client, then from # client to server), but described only in its first position. The one # message which is not bound by these ordering rules in the Hello # Request message, which can be sent at any time, but which should be # ignored by the client if it arrives in the middle of a handshake. TLS 1.1 (RFC 4346) same wording but with "must" -> "MUST". TLS 1.2 (RFC 5246) same wording but also with "should" -> "SHOULD". --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigD0A19434D5A1A2210F317B40 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksQ4jEACgkQWUc8YzyzqAe5kAD+MSg6niMc7lM1Xcj/XlrUaB00 4IbN7dZ3MPLJRjxEz2wA/3KJDwAEHziziuscCGOPFSThwWV87EAHM+irUOCM5Szp =sWq2 -----END PGP SIGNATURE----- --------------enigD0A19434D5A1A2210F317B40-- From djhopwood@googlemail.com Sat Nov 28 00:55:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D123A67D3 for ; Sat, 28 Nov 2009 00:55:04 -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 kJr7mNClEnXY for ; Sat, 28 Nov 2009 00:55:03 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id B15A53A679C for ; Sat, 28 Nov 2009 00:55:02 -0800 (PST) Received: by ewy6 with SMTP id 6so1263106ewy.29 for ; Sat, 28 Nov 2009 00:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=HGGWOglfeAoDIXw9/ztdFhfuAHTgux4sZf9fZPpbPPk=; b=rb0OmL/QbRUlS5Ocq/TviK1t6jNHgA0YHxUMGHq09c3uEaJ4CoqsNR/Ffmvb6QXqfD biLU5NiXwVyguc4s33SiW9bzl4cYx9QxceukjU/c0Jkrc6+S2RqIbiZGXO2lJbgJ+QuV 3Qdl3WEW9MQh0RHbG9IFu72COEEQDc1kDEcsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=x/n8f4RKvHXeTt7jJF54uRmU9Euf9x9PxsicSsaZdA9gsLDnU516w3MxXlqrYNFGge ts5t3Cx8sUDj/9xYAwRMZWevm8WdMzwZNG65QWLltQl5ryruc/85VYdyVQ96AQvmVFKr 6kul3PU9lNRaTHiObKAD0eEDSUsiLH1XHgHLM= Received: by 10.216.86.211 with SMTP id w61mr601777wee.6.1259398493340; Sat, 28 Nov 2009 00:54:53 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id i6sm5642252gve.16.2009.11.28.00.54.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Nov 2009 00:54:52 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B10E556.1050802@jacaranda.org> Date: Sat, 28 Nov 2009 08:54:46 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <32C4392B-749C-47D7-B625-C769A18DE9DE@checkpoint.com> In-Reply-To: <32C4392B-749C-47D7-B625-C769A18DE9DE@checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF6F6FB90D8197A967A56960A" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 08:55:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6F6FB90D8197A967A56960A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > On Nov 26, 2009, at 8:11 PM, Blumenthal, Uri - 0662 - MITLL wrote: >> On 11/26/09 12:23 , "David-Sarah Hopwood" = >> wrote: >>> Blumenthal, Uri - 0662 - MITLL wrote: >>>> Yes, previous_verify_data MUST be a part of the input to the PRF. Wh= at Yoav >>>> Nir said (XOR-ing it with the master_secret), should work (out of ha= nd - >>>> anybody sees a problem with it?). >>> >>> The previous_verify_data is not necessarily secret, so this requires = the >>> PRF to be secure against related-key attack. The particular PRFs used= in >>> SSLv3 and TLS 1.0 to 1.2 should be secure in that sense, but (if we >>> decide to use this approach) I still prefer what I suggested before: >>> >>> verify_data =3D >>> PRF(master_secret, finished_label, Hash(handshake_messages) >>> + previous_verify_data) >>> [0..verify_data_length-1]; >>> >>> which uses the PRF in a more conventional way. I no longer think we should use this approach; the arguments in favour of encoding the previous_verify_data in handshake_messages (see below) are compelling. [reordered] >> As for SSLv3 - SMNP (Simply Not My Problem :). Would be nice to >> address it as well, but I'd rather not bend over backwards to also >> fix SSLv3. SSLv3 is easy enough to fix without bending over backwards. > I don't see why my suggestion [XORing the master_secret with the > previous_verify_data when computing the new hashes] doesn't hold for > SSLv3 as well. It does, but the specification complexity is on the high side, given that= the computations would need to be spelled out for SSLv3 and TLS separatel= y, as well as changing CertificateVerify. Nelson's point about hardware security modules is another reason not to do this. Adding the previous_verify_data into handshake_messages is preferable because: - it treats SSLv3 and TLS entirely uniformly; - there is no problem with hardware security modules; - the use of hashing APIs is unchanged (unlike the suggestion to chain all messages in the previous session before those in the current session); - it automatically causes the previous_verify_data to be included in the data signed by CertificateVerify, when used. The obvious place to put it is just after ServerHello, since that is before CertificateVerify and is the first point at which both sides know that this session is renegotiated. The theoretical attacks that I was worried about are solved by using the encoding starting with bytes {20, 0, 0, 0} described in my followup to Eric Rescorla (subject "Verify data in the RI extension" -- it doesn't seem to be in the archive yet). --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigF6F6FB90D8197A967A56960A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksQ5V8ACgkQWUc8YzyzqAcRhAD/YCJ48gtCnBACPDyG3NG0OVQ0 VTvYDI3dV8uigOryysoA/3r7iXdSkwQ8/TumTNz9cs0k+3ZHajvyuZYREdBY8Hoe =zwZA -----END PGP SIGNATURE----- --------------enigF6F6FB90D8197A967A56960A-- From aerowolf@gmail.com Sat Nov 28 03:22:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F323A6807 for ; Sat, 28 Nov 2009 03:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 CHYNDW8NnT-D for ; Sat, 28 Nov 2009 03:22:25 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id D0E923A6783 for ; Sat, 28 Nov 2009 03:22:25 -0800 (PST) Received: by pwi6 with SMTP id 6so1449450pwi.29 for ; Sat, 28 Nov 2009 03:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YU937Czkx5Yldk3L1y9FSox9PSle41Sr3B8GVKyjib0=; b=mAU+6cOUWTMa4MpjNOJWTLtgcSQipsjQhrLB7udOHpcW5CJ/DHV0Q1JzfRY7UDMGyt y/jOXQaJ0ruEJbGnZaa1qsa9L4+VzFBUrOj7yg1GlWXFlSuO53fv+JUpHGQWrQIrgTqb GdJxBsC9kbohqW6eXyni0hLsrgJjclhoMoNyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rUvOqArVrqAjjLtap4fCFA5bSyBE5zFCHpIhzdym2UpYqYEXXuXFsL45BhH96sJIyU MGFKibiQqKhwG1b2zXtP6oDvueNhcPRfNctBP2T2Ttsdxc6zOmSX46YcvV23wPDyqRww C8w5D7aBZZiWhqdfRFqBC/6tSl7FfoYc9SvKw= MIME-Version: 1.0 Received: by 10.143.27.31 with SMTP id e31mr214742wfj.173.1259407337467; Sat, 28 Nov 2009 03:22:17 -0800 (PST) In-Reply-To: <20091125225408.42FB96C3288@kilo.networkresonance.com> References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> Date: Sat, 28 Nov 2009 03:22:17 -0800 Message-ID: <6b9359640911280322w32974bd9u6b791ede79260d5c@mail.gmail.com> From: Kyle Hamilton To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: TLS Working Group Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 11:22:27 -0000 On Wed, Nov 25, 2009 at 2:54 PM, Eric Rescorla w= rote: >> =C2=A0 =C2=A03) Incorporate previous verify_data into Finished calc. > > I'm not happy with this, actually. > > This requires breaking the current clean definition of handshake > hashes as the hash of all the handshake messages and simply adding > some synthetic message in the middle. I don't think this is anywhere > near as clean, as evidenced by the ongoing debate about whether to put > it the synthetic data in the front, the back, incorporate it into the > PRF, or chain the pre-existing handshake messages. [FWIW, I think I > prefer the last of these implicit versions.] I would prefer to think in terms of "save the handshake hash values after you verify them in Finished processing". This would allow them to be used as (essentially) initialization vectors for the next set of handshake messages, thus providing "Message Authentication Code continuity". (The reason the attack works is because the server doesn't properly authenticate the message, and the client can't know that anything untoward happened. The server doesn't chain any information from the prior handshake into the current handshake, the client doesn't chain any information from the prior handshake into the current handshake, and there's no way for either the server or client to tell the other exactly which negotiation epoch it thinks it's on. If the prior handshake's information isn't chained in, from a security standpoint it appears to be the same outcome as not verifying the MAC on any given record.) There shouldn't need to be any additional verify_data sent, since all the information for ensuring that the same client is talking with the same server is in those hashes. So, potential ways to resolve this include: 1) including a 'negotiation epoch' in the handshake (if the server thinks this is the first renegotiation, it's going to expect that the epoch received from the client would be 1, not 0... and same for subsequent negotiations). 2) Chain the last Finished hashes (NOT the master_secret or any key material) as the initialization vector for the next handshake's Finished MAC calculation. (If you think about it, this is pretty much the same as an epoch-based system, with each epoch 'named' by a semi-random string of bits.) Include the IV'd MAC as a field in the Finished structure, and keep the current MAC calculation in place (simply to simplify the lives of the vendors) -- which provides a useful safety net: if they are the same, it's epoch 0, and if they're not, it's not. Now that we have some idea of how to authenticate the new session as being an outgrowth of the prior, we now need to provide a means for clients and servers that do this to notify each other that they're using the modified handshake message algorithm. We have on the table: A) Secure Renegotiation Indicator TLS extension. B) Magic cipher_suite. C) Bit-fiddled version identifiers. We are constrained by the following: 1) The mechanism for signalling must not screw up the protocol steps for unpatched libraries. 2) The mechanism for signalling must be backward-compatible to SSLv3 (this is my interpretation of what the Area Director stated; please correct me if I am wrong). Because of constraint number 2, option A cannot be the mandated mechanism for the client to signal the server that it supports renegotiation continuity. It is absolutely daft to try to turn an integer into a bitfield, so option C is pretty much insane (and is also fairly incompatible with DTLS, since its version is a 2s-complement of the TLS version it's based on). This leaves option B as the only sane mechanism that meets both constraints, for the client to signal the server. However, once the protocol is patched, it can be patched in any manner the TLS group defines (and the TLS group has dominion over SSLv3, by default, too). So, the client's signal can tell the server that it's okay to use a slightly different Finished message, no matter which protocol version it's using -- one that includes a specific sequence of bytes (a "magic number", if you will) after the end of the normal Finished message. Now, define the hash/PRF to have IVs of the prior iteration's Finished hashes (each side has its own hash, so there's [a cryptographic question: is there a reason to include both Finished hashes as IV input to both the Server and the Client calculations? Or should it be sufficient to only include that side's prior hash?] (the initial vector for the first one is all bits clear), and you have a verifiable chain of channel "ownership". Am I misunderstanding the situation here? > By contrast, RI allows that part of the system (which is well > understood) to remain the same and in fact when RI is offered on the > first handshake, there is no change to the TLS core at all. It's all > just hashed into Finished as part of the ordinary TLS procedures, > and everything is in fact compliant TLS, which I think is desirable. The problem is this: all vendors -- not just a single vendor -- need to be able to implement whatever's here *quickly*. They need to do it not just for TLS, but also for That Pre-TLS Protocol That Refuses To Die. There's no reason to change one in a manner that's incompatible with the change made to the other. (SSLv3 needs the magic cipher suite, and that means that servers are going to have to support it if they want to talk to even IE7 (which, IIRC, enabled SSLv3 but not TLSv1.0). SSLv3 ClientHello is still going to be used, and relying only on an RI extension fails to support it. Thus, it's pretty much a non-starter. As the Area Director has stated, the IETF is in this to ensure that the network *works*, not to adhere to some ideologically 'pure' concept. SSLv3 is, unfortunately, going to have to be supported -- because if we suddenly break 75% of the clients on the network, not only the users but IT admins and CTOs alike are going to be *pissed*. An "unsolicited" empty RI extension from the server when it sees the magic cipher_suite is probably the cleanest way to insert the signalling required for any defense against the attack to work... the server would not send it unless the client sent the magic ciphersuite (or, following the TLS Extensions model, if the client offered it as an extension during negotiation). An unpatched server won't send the RI extension even if the client sends the magic cipher_suite, so the client should know not to renegotiate. An unpatched client won't send either the magic cipher_suite or the RI extension, so the server should know not to renegotiate (and thus won't send the RI extension -- again following the extensions model, with an addendum that the RI extension is the only one that can be requested with a magic cipher_suite being prepended to the actual list of ciphers that the client's willing to use). > I appreciate that this is to some extent a matter of tradeoffs, > but I don't find the arguments in favor of the implicit version > very compelling when weighed against the above. "Implicit version"? There is no "implicit version" in the Moeller/D'Errico proposal. The version structure is never touched at all. -Kyle H From ekr@networkresonance.com Sat Nov 28 07:05:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24683A68FF for ; Sat, 28 Nov 2009 07:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiU1lV0dsRwZ for ; Sat, 28 Nov 2009 07:05:06 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id AC22C3A68B8 for ; Sat, 28 Nov 2009 07:05:02 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 6D24B6C3ABB; Sat, 28 Nov 2009 07:05:47 -0800 (PST) Date: Sat, 28 Nov 2009 07:05:46 -0800 From: Eric Rescorla To: Kyle Hamilton In-Reply-To: <6b9359640911280322w32974bd9u6b791ede79260d5c@mail.gmail.com> References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <6b9359640911280322w32974bd9u6b791ede79260d5c@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091128150547.6D24B6C3ABB@kilo.networkresonance.com> Cc: TLS Working Group Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 15:05:07 -0000 At Sat, 28 Nov 2009 03:22:17 -0800, Kyle Hamilton wrote: > > I appreciate that this is to some extent a matter of tradeoffs, > > but I don't find the arguments in favor of the implicit version > > very compelling when weighed against the above. > > "Implicit version"? There is no "implicit version" in the > Moeller/D'Errico proposal. The version structure is never touched at > all. What's implicit is that the verify data is not explicitly carried over the wire but implicitly inserted into the handshake hashes. I agree that this isn't that great a name for the distinction. -Ekr From uri@ll.mit.edu Sat Nov 28 08:19:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A8E3A68FF for ; Sat, 28 Nov 2009 08:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQHWgb-xcOWi for ; Sat, 28 Nov 2009 08:19:07 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 467393A68DF for ; Sat, 28 Nov 2009 08:19:05 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nASGIvfc024732 for ; Sat, 28 Nov 2009 11:18:57 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAh7aiXS; Sat Nov 28 11:14:50 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Sat, 28 Nov 2009 11:14:50 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Sat, 28 Nov 2009 11:14:49 -0500 Thread-Topic: [TLS] Quest for Unified Solution to TLS Renegotiation Thread-Index: AcpwCHl+fe77d4nPSbyXK9RmfejFsQAPW98v Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F4B@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 16:19:08 -0000 SSdtIE9LIHdpdGggaXQuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTog dGxzLWJvdW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IHRsc0BpZXRm Lm9yZyA8dGxzQGlldGYub3JnPg0KU2VudDogU2F0IE5vdiAyOCAwMzo1NDo0NiAyMDA5ClN1Ympl Y3Q6IFJlOiBbVExTXSBRdWVzdCBmb3IgVW5pZmllZCBTb2x1dGlvbiB0byBUTFMgUmVuZWdvdGlh dGlvbg0KDQpZb2F2IE5pciB3cm90ZToNCj4gT24gTm92IDI2LCAyMDA5LCBhdCA4OjExIFBNLCBC bHVtZW50aGFsLCBVcmkgLSAwNjYyIC0gTUlUTEwgd3JvdGU6DQo+PiBPbiAxMS8yNi8wOSAgMTI6 MjMgLCAiRGF2aWQtU2FyYWggSG9wd29vZCIgPGRhdmlkLXNhcmFoQGphY2FyYW5kYS5vcmc+DQo+ PiB3cm90ZToNCj4+PiBCbHVtZW50aGFsLCBVcmkgLSAwNjYyIC0gTUlUTEwgd3JvdGU6DQo+Pj4+ IFllcywgcHJldmlvdXNfdmVyaWZ5X2RhdGEgTVVTVCBiZSBhIHBhcnQgb2YgdGhlIGlucHV0IHRv IHRoZSBQUkYuIFdoYXQgWW9hdg0KPj4+PiBOaXIgc2FpZCAoWE9SLWluZyBpdCB3aXRoIHRoZSBt YXN0ZXJfc2VjcmV0KSwgc2hvdWxkIHdvcmsgKG91dCBvZiBoYW5kIC0NCj4+Pj4gYW55Ym9keSBz ZWVzIGEgcHJvYmxlbSB3aXRoIGl0PykuDQo+Pj4NCj4+PiBUaGUgcHJldmlvdXNfdmVyaWZ5X2Rh dGEgaXMgbm90IG5lY2Vzc2FyaWx5IHNlY3JldCwgc28gdGhpcyByZXF1aXJlcyB0aGUNCj4+PiBQ UkYgdG8gYmUgc2VjdXJlIGFnYWluc3QgcmVsYXRlZC1rZXkgYXR0YWNrLiBUaGUgcGFydGljdWxh ciBQUkZzIHVzZWQgaW4NCj4+PiBTU0x2MyBhbmQgVExTIDEuMCB0byAxLjIgc2hvdWxkIGJlIHNl Y3VyZSBpbiB0aGF0IHNlbnNlLCBidXQgKGlmIHdlDQo+Pj4gZGVjaWRlIHRvIHVzZSB0aGlzIGFw cHJvYWNoKSBJIHN0aWxsIHByZWZlciB3aGF0IEkgc3VnZ2VzdGVkIGJlZm9yZToNCj4+Pg0KPj4+ ICAgIHZlcmlmeV9kYXRhID0NCj4+PiAgICAgIFBSRihtYXN0ZXJfc2VjcmV0LCBmaW5pc2hlZF9s YWJlbCwgSGFzaChoYW5kc2hha2VfbWVzc2FnZXMpDQo+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICsgcHJldmlvdXNfdmVyaWZ5X2RhdGEpDQo+Pj4gICAgICAgIFsw Li52ZXJpZnlfZGF0YV9sZW5ndGgtMV07DQo+Pj4NCj4+PiB3aGljaCB1c2VzIHRoZSBQUkYgaW4g YSBtb3JlIGNvbnZlbnRpb25hbCB3YXkuDQoNCkkgbm8gbG9uZ2VyIHRoaW5rIHdlIHNob3VsZCB1 c2UgdGhpcyBhcHByb2FjaDsgdGhlIGFyZ3VtZW50cyBpbiBmYXZvdXINCm9mIGVuY29kaW5nIHRo ZSBwcmV2aW91c192ZXJpZnlfZGF0YSBpbiBoYW5kc2hha2VfbWVzc2FnZXMgKHNlZSBiZWxvdykN CmFyZSBjb21wZWxsaW5nLg0KDQpbcmVvcmRlcmVkXQ0KPj4gQXMgZm9yIFNTTHYzIC0gU01OUCAo U2ltcGx5IE5vdCBNeSBQcm9ibGVtIDopLiBXb3VsZCBiZSBuaWNlIHRvDQo+PiBhZGRyZXNzIGl0 IGFzIHdlbGwsIGJ1dCBJJ2QgcmF0aGVyIG5vdCBiZW5kIG92ZXIgYmFja3dhcmRzIHRvIGFsc28N Cj4+IGZpeCBTU0x2My4NCg0KU1NMdjMgaXMgZWFzeSBlbm91Z2ggdG8gZml4IHdpdGhvdXQgYmVu ZGluZyBvdmVyIGJhY2t3YXJkcy4NCg0KPiBJIGRvbid0IHNlZSB3aHkgbXkgc3VnZ2VzdGlvbiBb WE9SaW5nIHRoZSBtYXN0ZXJfc2VjcmV0IHdpdGggdGhlDQo+IHByZXZpb3VzX3ZlcmlmeV9kYXRh IHdoZW4gY29tcHV0aW5nIHRoZSBuZXcgaGFzaGVzXSBkb2Vzbid0IGhvbGQgZm9yDQo+IFNTTHYz IGFzIHdlbGwuDQoNCkl0IGRvZXMsIGJ1dCB0aGUgc3BlY2lmaWNhdGlvbiBjb21wbGV4aXR5IGlz IG9uIHRoZSBoaWdoIHNpZGUsIGdpdmVuIHRoYXQNCnRoZSBjb21wdXRhdGlvbnMgd291bGQgbmVl ZCB0byBiZSBzcGVsbGVkIG91dCBmb3IgU1NMdjMgYW5kIFRMUyBzZXBhcmF0ZWx5LA0KYXMgd2Vs bCBhcyBjaGFuZ2luZyBDZXJ0aWZpY2F0ZVZlcmlmeS4gTmVsc29uJ3MgcG9pbnQgYWJvdXQgaGFy ZHdhcmUNCnNlY3VyaXR5IG1vZHVsZXMgaXMgYW5vdGhlciByZWFzb24gbm90IHRvIGRvIHRoaXMu DQoNCkFkZGluZyB0aGUgcHJldmlvdXNfdmVyaWZ5X2RhdGEgaW50byBoYW5kc2hha2VfbWVzc2Fn ZXMgaXMgcHJlZmVyYWJsZQ0KYmVjYXVzZToNCiAtIGl0IHRyZWF0cyBTU0x2MyBhbmQgVExTIGVu dGlyZWx5IHVuaWZvcm1seTsNCiAtIHRoZXJlIGlzIG5vIHByb2JsZW0gd2l0aCBoYXJkd2FyZSBz ZWN1cml0eSBtb2R1bGVzOw0KIC0gdGhlIHVzZSBvZiBoYXNoaW5nIEFQSXMgaXMgdW5jaGFuZ2Vk ICh1bmxpa2UgdGhlIHN1Z2dlc3Rpb24gdG8NCiAgIGNoYWluIGFsbCBtZXNzYWdlcyBpbiB0aGUg cHJldmlvdXMgc2Vzc2lvbiBiZWZvcmUgdGhvc2UgaW4gdGhlDQogICBjdXJyZW50IHNlc3Npb24p Ow0KIC0gaXQgYXV0b21hdGljYWxseSBjYXVzZXMgdGhlIHByZXZpb3VzX3ZlcmlmeV9kYXRhIHRv IGJlIGluY2x1ZGVkDQogICBpbiB0aGUgZGF0YSBzaWduZWQgYnkgQ2VydGlmaWNhdGVWZXJpZnks IHdoZW4gdXNlZC4NCg0KVGhlIG9idmlvdXMgcGxhY2UgdG8gcHV0IGl0IGlzIGp1c3QgYWZ0ZXIg U2VydmVySGVsbG8sIHNpbmNlIHRoYXQgaXMNCmJlZm9yZSBDZXJ0aWZpY2F0ZVZlcmlmeSBhbmQg aXMgdGhlIGZpcnN0IHBvaW50IGF0IHdoaWNoIGJvdGggc2lkZXMNCmtub3cgdGhhdCB0aGlzIHNl c3Npb24gaXMgcmVuZWdvdGlhdGVkLg0KDQpUaGUgdGhlb3JldGljYWwgYXR0YWNrcyB0aGF0IEkg d2FzIHdvcnJpZWQgYWJvdXQgYXJlIHNvbHZlZCBieSB1c2luZw0KdGhlIGVuY29kaW5nIHN0YXJ0 aW5nIHdpdGggYnl0ZXMgezIwLCAwLCAwLCAwfSBkZXNjcmliZWQgaW4gbXkNCmZvbGxvd3VwIHRv IEVyaWMgUmVzY29ybGEgKHN1YmplY3QgIlZlcmlmeSBkYXRhIGluIHRoZSBSSSBleHRlbnNpb24i IC0tDQppdCBkb2Vzbid0IHNlZW0gdG8gYmUgaW4gdGhlIGFyY2hpdmUgeWV0KS4NCg0KLS0gDQpE YXZpZC1TYXJhaCBIb3B3b29kICDimqUgIGh0dHA6Ly9kYXZpZHNhcmFoLmxpdmVqb3VybmFsLmNv bQ0KDQo= From djhopwood@googlemail.com Sat Nov 28 10:26:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFBE3A6875 for ; Sat, 28 Nov 2009 10:26:21 -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 8g+NzbIZJ2xN for ; Sat, 28 Nov 2009 10:26:20 -0800 (PST) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id 485A03A67D9 for ; Sat, 28 Nov 2009 10:26:20 -0800 (PST) Received: by ewy1 with SMTP id 1so2546865ewy.14 for ; Sat, 28 Nov 2009 10:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=LJZ0jW9MM1lfU1Lw9Ylhq43uMMFUP1QVYt3yXQLJseQ=; b=wRjt58JQOACZmSwGTMu/tvjLLoqGlZRgmH9qIeXvAkWCpf8WNsrU+EKeSEICikJcsm FzPmMOLlXLxb4Suh4c568/p3TyyE0zytUNTUk07Qe38y1rXGxkUKuS/ZKjvVKcxwJDzE OEDMW4kJ5pUpMrCXjodcfXqPu3/9HV3w7vxWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=j566ZmCgB47qLvelMVCgkjvIsLG/8I9urceMONicA06mB1oTcm7d1hAIk6JEmrBrD3 aaFKMfv+A3aPL3uD2JpKX7aUYuqVNjn/dbPT0L9usaezvsmQJuOHrVS0Ysh1d/3s1ggC sDX2vmA57SdeASjGeAh6kcVvRT4oVqcrAQ+Wg= Received: by 10.216.85.197 with SMTP id u47mr771335wee.133.1259432770359; Sat, 28 Nov 2009 10:26:10 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id m5sm6687207gve.12.2009.11.28.10.26.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Nov 2009 10:26:09 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B116B4C.1070309@jacaranda.org> Date: Sat, 28 Nov 2009 18:26:20 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <6b9359640911280322w32974bd9u6b791ede79260d5c@mail.gmail.com> In-Reply-To: <6b9359640911280322w32974bd9u6b791ede79260d5c@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8C967B73868E220F3C0FF8C4" Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 18:26:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8C967B73868E220F3C0FF8C4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kyle Hamilton wrote: > A) Secure Renegotiation Indicator TLS extension. > B) Magic cipher_suite. > C) Bit-fiddled version identifiers. >=20 > We are constrained by the following: >=20 > 1) The mechanism for signalling must not screw up the protocol steps > for unpatched libraries. > 2) The mechanism for signalling must be backward-compatible to SSLv3 > (this is my interpretation of what the Area Director stated; please > correct me if I am wrong). >=20 > Because of constraint number 2, option A cannot be the mandated > mechanism for the client to signal the server that it supports > renegotiation continuity. That's not correct. Option A for S->C signalling works fine in SSLv3. In the case where the server does not already support extensions, it's just appending a fixed octet string to the ServerHello, so it is no more difficult to implement than any other option. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig8C967B73868E220F3C0FF8C4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksRa1MACgkQWUc8YzyzqAfknwEAnY+P0eOaYk04noACkt9GPMc9 MIZfC+G1q7Uw7b7G3jcBAJ9NVD854ueVTn5TwkIprsBgysOAvqh3NWMzopK7tTr6 =xhJu -----END PGP SIGNATURE----- --------------enig8C967B73868E220F3C0FF8C4-- From mike-list@pobox.com Sat Nov 28 11:31:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B123A6901 for ; Sat, 28 Nov 2009 11:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 EKdwuEzMibNL for ; Sat, 28 Nov 2009 11:31:42 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 33C553A68D0 for ; Sat, 28 Nov 2009 11:31:40 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E77CBA2595 for ; Sat, 28 Nov 2009 14:31:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=YVxVd9dWqVmy HkyMBcPi2aQPiNA=; b=eZPo4hlY+enJcu+tRLFjZ1EHkDGkNHjtR7Y4ijmUHLIZ 5rF8kX28OuxK4uUQ7smxzYrEgFUAVTBTjs/8pvV8/kTp3cHdiHrtJHOyi5YmRDfY MYSmvwIw+FYodagx6WZI1Nhv6eUHIHb9II6P2oqr4YfxbXHjv1xRu6ZNqaZcr60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=utCazN dEQzBjRz6GEiQtsYcRm0W7kygGyvSFYLPWwn0m3lGmuG5sBeScFqTMumj31vEy5V EQvgwHP2mDg/uT5Yg7D/9pzqJwTi/m/Pa69OfihqPR4/H92iogM6YP99Bsfwfonc +L/r+02tsqfpAqr6ffdkYi4BzrLpi1xVhAwUw= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E2AE5A2593 for ; Sat, 28 Nov 2009 14:31:33 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 953EAA2592 for ; Sat, 28 Nov 2009 14:31:33 -0500 (EST) Message-ID: <4B117AF2.20703@pobox.com> Date: Sat, 28 Nov 2009 11:33:06 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> In-Reply-To: <4B10E225.4010501@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: A310FC16-DC54-11DE-BE05-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 19:31:43 -0000 David-Sarah Hopwood wrote: > Eric Rescorla wrote: >> I also share [David-Sarah] Hopwood's concern about ambiguity in the handshake >> hashes stream created by having data which is not properly formatted >> injected into the hash >> (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html), >> so I don't think the particular approach in Martin's draft is >> really satisfactory. > > That potential weakness can be avoided by encoding the data to be added > into the hash as follows: > > struct { > enum { fake_finished(20) } fake_handshake_type; > enum { zero(0), (2^24-1) } fake_length; > opaque previous_client_verify_data<12..255>; > opaque previous_server_verify_data<12..255>; > } PreviousVerifyData; I like the direction this is going, but think that using a length of zero doesn't quite patch the potential weakness. So instead of zero, why not use 0xFFFFFF? An attack would require that a 16MB Finished message be ignored. Mike From djhopwood@googlemail.com Sat Nov 28 16:33:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985F53A67E7 for ; Sat, 28 Nov 2009 16:33:44 -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 aE5lTERn-+sP for ; Sat, 28 Nov 2009 16:33:43 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 3B4523A67C0 for ; Sat, 28 Nov 2009 16:33:43 -0800 (PST) Received: by ewy7 with SMTP id 7so3101009ewy.28 for ; Sat, 28 Nov 2009 16:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=7knYYOA3mdGbHybvMkrKZQTb1K397Xeq8eRoKqFkhSY=; b=IJKRDEPSu9+u3J0ne+XdgtXBAyOyyAj9y82rQkZeS1dfWb43XQk35sPtO6pKWRvnH9 i8cWeuKC6Y3ZZ7TcCVwWuRHsH2iuRCI2OBOJ437NN7ZYrrnOkwch0DzgExih/u03HzY2 SfOvNoTkvzFlsNOP1iN7CxfuJJ/3tXy8z7mCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=JIO1ce1Umh8ymdj4aZ4QMbT+ZXG9rnE6eUzZfVBrdNswWgyrqcbGV6DqCbwAITHFCA gLIcrjnmCCb/ZzqLAgH945i99+JZ7r7lY3GzvFrZJJaJ1wK7Y+YqmsNaKvz+DV8xkn+O mdmU0sGWxwr3nP4culC3zUkkX9ejNu7BlGfcw= Received: by 10.216.88.139 with SMTP id a11mr843621wef.50.1259454812467; Sat, 28 Nov 2009 16:33:32 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id n12sm7102556gve.29.2009.11.28.16.33.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Nov 2009 16:33:31 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B11C156.7060204@jacaranda.org> Date: Sun, 29 Nov 2009 00:33:26 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> <4B117AF2.20703@pobox.com> In-Reply-To: <4B117AF2.20703@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB512E07993C521E8F3DE6897" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 00:33:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB512E07993C521E8F3DE6897 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > David-Sarah Hopwood wrote: >> Eric Rescorla wrote: >>> I also share [David-Sarah] Hopwood's concern about ambiguity in the >>> handshake hashes stream created by having data which is not properly >>> formatted injected into the hash >>> (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html), >>> so I don't think the particular approach in Martin's draft is >>> really satisfactory. >> >> That potential weakness can be avoided by encoding the data to be adde= d >> into the hash as follows: >> >> struct { >> enum { fake_finished(20) } fake_handshake_type; >> enum { zero(0), (2^24-1) } fake_length; >> opaque previous_client_verify_data<12..255>; >> opaque previous_server_verify_data<12..255>; >> } PreviousVerifyData; >=20 > I like the direction this is going, but think that using a length of > zero doesn't quite patch the potential weakness. It does: as I said, for an implementation to be vulnerable it would have to violate two existing 'MUST's -- failing to abort the handshake on an out-of-order handshake message, and failing to check the correctnes= s of the verify_data in a Finished message. If it gets the latter wrong, then it's clearly insecure anyway. What is sent after the fake Finished message doesn't matter for avoiding this weakness. (Since the previous_{client,server}_verify_data are variable-length, I chose to encode their length explicitly, but that's a separate issue.) > So instead of zero, why not use 0xFFFFFF? That would work as well, but only for the same reason, i.e. that 0xFFFFFF is not a valid length for the content of a correct Finished message. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB512E07993C521E8F3DE6897 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksRwWoACgkQWUc8YzyzqAcuvwD6AvLer5ySEtMk5zpT1zgBRXxC ZjiEkfVoN89tcXxDivcA/ia9KFqaBdl/AHonDsRNp1QyErfCW/96cywOkaIfslxx =fIPL -----END PGP SIGNATURE----- --------------enigB512E07993C521E8F3DE6897-- From geoffk@apple.com Sat Nov 28 19:27:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4B23A6925 for ; Sat, 28 Nov 2009 19:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jOkgQMJMAkpN for ; Sat, 28 Nov 2009 19:27:20 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id B96C43A6825 for ; Sat, 28 Nov 2009 19:27:20 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id CD0DD80E2B20 for ; Sat, 28 Nov 2009 19:27:13 -0800 (PST) X-AuditID: 11807136-b7bafae000000e8d-cb-4b11ea11837f Received: from [17.151.122.21] (Unknown_Domain [17.151.122.21]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id EC.0F.03725.11AE11B4; Sat, 28 Nov 2009 19:27:13 -0800 (PST) From: Geoffrey Keating Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Nov 2009 19:27:13 -0800 Message-Id: <59FE2EFB-F8EC-489D-AFCE-3D3C29291ADF@apple.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= X-Mailman-Approved-At: Sat, 28 Nov 2009 19:42:15 -0800 Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 03:32:59 -0000 Apple supports this draft, with the following modification: The draft does not address the security issue for existing clients = unless it requires that renegotiation occur only when the extension is = present. I suggest strengthening the language in 4.2 to read To prevent such attacks, servers MUST NOT allow clients who do not offer = the "renegotiation_info" extension to complete a renegotiation. If the = client initiated the renegotiation the server SHOULD respond to such = requests with a "no_renegotiation" alert [RFC 5246 requires this alert = to be at the "warning" level.] If the server initiated the = renegotiation the fatal "handshake_failure" alert is appropriate. and delete the sentence 'Servers SHOULD follow this behaviour'. With this modification, section 4.1.1 is redundant and may be deleted. = It is also possible to delete section 4.3 as with this modification, if = the client is convinced to drop the extension, either servers support = the draft and will refuse to renegotiate without the extension and are = still secure, or don't support the draft and will ignore the extension, = and so would be insecure anyway.= From mike-list@pobox.com Sat Nov 28 20:42:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48B83A6844 for ; Sat, 28 Nov 2009 20:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 drpIeKZwlorK for ; Sat, 28 Nov 2009 20:42:13 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 948123A67E3 for ; Sat, 28 Nov 2009 20:42:12 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 979EE83EDA for ; Sat, 28 Nov 2009 23:42:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rbq6Q5XmDCIk YIw2oyLtnb8fFO4=; b=BLLRLf5bGVQY7i9FEW2pi3VI8EDXb5b9vb0rionFKzU0 8uIhLNNJllAeFnbSramiznR4/GDOFDFn52Akgnthe2ejRgXp6pIvf1zksFYw7k0x THP1nCHumQkz5/sn2P6J6KQoZPm6bFfmYuHwZsAsYfQLxngTxYtNSJJTKedpXPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=uFbVPP bmd9fwkJaDFE0ABK85C81Tst8dGd0E2CJvpvXRSS/+1BoKkKck/Aj5/pbNq6430f GPW9dvbpz0s25v6BeDcnzZA1FzT6m2S3E/fIELxNTUyl6gpdq7S4cY4HIib96TMu CzNk5A3f74AjTwPTSvwEzjUPxj8LQ0I3uAhtU= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 946BC83ED9 for ; Sat, 28 Nov 2009 23:42:05 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 1F15083ED8 for ; Sat, 28 Nov 2009 23:42:04 -0500 (EST) Message-ID: <4B11FBF8.8080400@pobox.com> Date: Sat, 28 Nov 2009 20:43:36 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> <4B117AF2.20703@pobox.com> <4B11C156.7060204@jacaranda.org> In-Reply-To: <4B11C156.7060204@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 8B7CCFE2-DCA1-11DE-AF24-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 04:42:14 -0000 David-Sarah Hopwood wrote: > Michael D'Errico wrote: >> David-Sarah Hopwood wrote: >>> Eric Rescorla wrote: >>>> I also share [David-Sarah] Hopwood's concern about ambiguity in the >>>> handshake hashes stream created by having data which is not properly >>>> formatted injected into the hash >>>> (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html), >>>> so I don't think the particular approach in Martin's draft is >>>> really satisfactory. >>> That potential weakness can be avoided by encoding the data to be added >>> into the hash as follows: >>> >>> struct { >>> enum { fake_finished(20) } fake_handshake_type; >>> enum { zero(0), (2^24-1) } fake_length; >>> opaque previous_client_verify_data<12..255>; >>> opaque previous_server_verify_data<12..255>; >>> } PreviousVerifyData; >> I like the direction this is going, but think that using a length of >> zero doesn't quite patch the potential weakness. > > It does: as I said, for an implementation to be vulnerable it would > have to violate two existing 'MUST's -- failing to abort the handshake > on an out-of-order handshake message, and failing to check the correctness > of the verify_data in a Finished message. If it gets the latter wrong, > then it's clearly insecure anyway. What is sent after the fake Finished > message doesn't matter for avoiding this weakness. The theoretical weakness, as I understand it, is that inserting the previous verify_data directly into the handshake message stream would allow an attacker to send the previous data to an unpatched peer at the point where it would get inserted by a patched peer. If (and it's a big if) that peer ignores that data, then the handshake has the possibility of completing. Your fix is to insert a "fake" header in front of the verify_data to make the attack impossible. The problem with using a zero length is that the 4-byte header you inserted is a _valid zero-length Finished message_. If you believe that the theoretical attack can work, then you have to also believe that it's possible for that broken peer to ignore a zero-length Finished message. Using any length that is longer than the inserted data should completely plug this hole. Mike > (Since the previous_{client,server}_verify_data are variable-length, > I chose to encode their length explicitly, but that's a separate issue.) > >> So instead of zero, why not use 0xFFFFFF? > > That would work as well, but only for the same reason, i.e. that > 0xFFFFFF is not a valid length for the content of a correct Finished > message. From djhopwood@googlemail.com Sat Nov 28 21:25:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF8A3A687B for ; Sat, 28 Nov 2009 21:25:16 -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 wJFLK+-9ECxB for ; Sat, 28 Nov 2009 21:25:15 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 004EC3A672E for ; Sat, 28 Nov 2009 21:25:14 -0800 (PST) Received: by ewy7 with SMTP id 7so3214265ewy.28 for ; Sat, 28 Nov 2009 21:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=An5IydWJXapKhpt5zYQjxhL0YGFSfZGGQCalz/CVGzk=; b=QIA8RwRC/3t03jhhKD82nz1yTfMFLJo37nXyltMk+t0Jh0R4Vf6UfRa1zDkff809Z7 cecuJO5i+VSRCXmYGEP9joEMjACA65Ap+7/c/FvDvPlWJCaFS/e8XURe0MtW/pPv9BaQ eb5/DYhXRyKpmsVR4bZnfdnLShIuS1oKHAOzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=pzTeia3qxUb4sm/zrQnheY1dZWz8hG2JxEg7US0XNgk9Mmtp5qf5c6sL/uSFvw11a0 4LYLAqJjyYsOtyfPA9g12/aZI292l744EZQcCEp3sFM303VAR/XLFhIRf8ktSPC9HQhG KW/kMZeWTtTnFzOwcamH7yQzA8YZ2MfRxmdSY= Received: by 10.216.85.69 with SMTP id t47mr915132wee.107.1259472305268; Sat, 28 Nov 2009 21:25:05 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id t12sm7356390gvd.5.2009.11.28.21.25.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Nov 2009 21:25:04 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1205AC.3060106@jacaranda.org> Date: Sun, 29 Nov 2009 05:25:00 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> <4B117AF2.20703@pobox.com> <4B11C156.7060204@jacaranda.org> <4B11FBF8.8080400@pobox.com> In-Reply-To: <4B11FBF8.8080400@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig952F11093D7BA23558899837" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 05:25:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig952F11093D7BA23558899837 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > David-Sarah Hopwood wrote: >> Michael D'Errico wrote: >>> David-Sarah Hopwood wrote: [...] >>>> That potential weakness can be avoided by encoding the data to be ad= ded >>>> into the hash as follows: >>>> >>>> struct { >>>> enum { fake_finished(20) } fake_handshake_type; >>>> enum { zero(0), (2^24-1) } fake_length; >>>> opaque previous_client_verify_data<12..255>; >>>> opaque previous_server_verify_data<12..255>; >>>> } PreviousVerifyData; >>> I like the direction this is going, but think that using a length of >>> zero doesn't quite patch the potential weakness. >> >> It does: as I said, for an implementation to be vulnerable it would >> have to violate two existing 'MUST's -- failing to abort the handshake= >> on an out-of-order handshake message, and failing to check the >> correctness of the verify_data in a Finished message. If it gets the >> latter wrong, then it's clearly insecure anyway. What is sent after >> the fake Finished message doesn't matter for avoiding this weakness. >=20 > The theoretical weakness, as I understand it, is that inserting the > previous verify_data directly into the handshake message stream would > allow an attacker to send the previous data to an unpatched peer at the= > point where it would get inserted by a patched peer. If (and it's a > big if) that peer ignores that data, then the handshake has the possibi= lity > of completing. The problem was that it wasn't possible to infer from the spec that any possible extra handshake message at that point would cause an abort. For the Finished message, it is possible to infer that it will. > Your fix is to insert a "fake" header in front of the verify_data to ma= ke > the attack impossible. The problem with using a zero length is that th= e > 4-byte header you inserted is a _valid zero-length Finished message_. No, a valid Finished message would have to include a verify_data hash (36 bytes in SSLv3; 12 bytes or more in TLS). It isn't plausible to suppose that an implementation that is secure in other respects would just ignore an extra Finished message of the wrong length and not containing the right hash. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig952F11093D7BA23558899837 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksSBbsACgkQWUc8YzyzqAcATgD/dPI5Fh7WTodGjpNNVQswF+P1 ebHx4NDw9Yyn5Og1o6AA/R7Xs7fWzecx/p4g/28uaURu3cgV1tivhb4FV0VQdwOX =9quW -----END PGP SIGNATURE----- --------------enig952F11093D7BA23558899837-- From SRS0=dAnb=HR=acm.org=bmoeller@srs.kundenserver.de Sun Nov 29 02:12:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0018D3A67F0 for ; Sun, 29 Nov 2009 02:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.204 X-Spam-Level: X-Spam-Status: No, score=-102.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 G7Jkd8on5035 for ; Sun, 29 Nov 2009 02:12:53 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id DE02B3A6782 for ; Sun, 29 Nov 2009 02:12:52 -0800 (PST) Received: from [10.1.120.118] ([74.125.121.49]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MOkOU-1NArXk3ol4-005Zao; Sun, 29 Nov 2009 11:12:40 +0100 From: Bodo Moeller To: David-Sarah Hopwood In-Reply-To: <4B10E225.4010501@jacaranda.org> References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 29 Nov 2009 11:12:37 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+xciekni19FgLdFfcvxYWwJ4wolEl0FiWMhyt pNDcQ3ewVjhfwpkTKxZaT5r+PuJfChAeL/60k4uNIkt/FvINAy S+XzZzNj6WlJOBvZPQ1ig== Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 10:16:22 -0000 On Nov 28, 2009, at 9:41 AM, David-Sarah Hopwood wrote: > Eric Rescorla wrote: >> I also share [David-Sarah] Hopwood's concern about ambiguity in the >> handshake >> hashes stream created by having data which is not properly formatted >> injected into the hash >> (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html), >> so I don't think the particular approach in Martin's draft is >> really satisfactory. > > That potential weakness can be avoided by encoding the data to be > added > into the hash as follows: > > struct { > enum { fake_finished(20) } fake_handshake_type; > enum { zero(0), (2^24-1) } fake_length; > opaque previous_client_verify_data<12..255>; > opaque previous_server_verify_data<12..255>; > } PreviousVerifyData; > > This works because the bytes {20, 0, 0, 0} encode a zero-length > Finished message, which if they actually appeared on the wire as > a handshake message sent in either direction, would cause the > recipient to abort the handshake. (This is similar to what Martin > suggested in a recent post. Since any fake_length that is not a > valid length for verify_data will work, we might as well use 0.) > > Note that for the receiver of the extra data to fail to abort the > handshake in that case, it would have to make two independent errors, > both violating 'MUST' requirements present since SSLv3: it would have > to accept the empty Finished message out-of-order [*], *and* not > check that the contents of that message is a correct verify_data hash. Arguably a single receiver-side bug might be enough -- namely, having a receiver *ignore* out-of-sequence messages without looking at their content. Then if an adversary includes the above in the actual handshake data sent to one of the peers, the receiver would interpret the concatenation previous_client_verify_data || previous_server_verify_data as one or more additional handshake messages, might similarly ignore these as unexpected, and with a non- negligible probability would end up at the correct message boundary to parse the next actual handshake message. (Encoding the actual combined length of the previous_..._verify_data fields seems simpler to analyze -- this still wouldn't be a valid Finished message; or hash an empty Finished first, then a pseudo- message containing the previous verify data. Of course, neither of this avoids the potential problem with buggy receivers that ignore out- of-sequence messages. That pseudo-message *could* use the Certificate type to maximize the probability that buggy implementations will look at it and stop [given that Certificate is expected at that point of the protocol], but I guess that looks even weirder.) Bodo From SRS0=dAnb=HR=acm.org=bmoeller@srs.kundenserver.de Sun Nov 29 02:23:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E7A3A6840 for ; Sun, 29 Nov 2009 02:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Xrb-gEyFzBTj for ; Sun, 29 Nov 2009 02:23:32 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 609933A677E for ; Sun, 29 Nov 2009 02:23:32 -0800 (PST) Received: from [10.1.120.118] ([74.125.121.49]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M7VWZ-1O20433gcJ-00x80w; Sun, 29 Nov 2009 11:23:25 +0100 From: Bodo Moeller To: David-Sarah Hopwood In-Reply-To: <4B10A613.9070506@jacaranda.org> References: <4B0EF1AB.8050506@extendedsubset.com> <6A2B0911-C59D-4A11-94FA-713E46E89488@acm.org> <4B10A184.4050107@jacaranda.org> <4B10A613.9070506@jacaranda.org> Message-Id: <63315D85-3C09-456D-A7A0-4A77BB603A27@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 29 Nov 2009 11:23:23 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+jvN7iebDJFuj6Zu1wZquekV6GzxQE8ZDDMTJ XMkYftrzsqCUY60Z+4IvqObJDA5FuL0mA3Z40QGi+Npaz0MH3O +7g3hBB0QazrP3fAWzyGA== Cc: tls@ietf.org Subject: Re: [TLS] What would be the point of removing signalling in TLS 1.3? [correction] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 10:23:33 -0000 On Nov 28, 2009, at 5:24 AM, David-Sarah Hopwood wrote: > David-Sarah Hopwood wrote: >> Bodo Moeller wrote: >>> On Nov 26, 2009, at 10:22 PM, Marsh Ray wrote: >>>> Stefan Santesson wrote: >>>>> If you fix the Finished message calculation, making it immune to >>>>> the >>>>> renegotiation attack, and making it the standard Finished >>>>> calculation >>>>> for >>>>> 1.3.... Then why would you need to signal that you are using the >>>>> standard >>>>> Finished calculation? >>>> So that clients and servers can be upgraded over a period of time >>>> without causing interoperability problems. >>> There are more than two ways how to treat signaling (how to signal >>> that >>> a new Finished computation should be used) with respect to future >>> protocol versions, i.e., TLS 1.3 and later: >> >> [numbering added] >>> 1. The specifications could mandate keeping the explicit signal >>> even with >>> TLS 1.3+. >>> >>> 2. The specifications could require an explicit signal only for >>> those TLS >>> 1.3+ implementations that do offer backwards compatibility with >>> earlier >>> protocol versions (i.e., if the *negotiated* protocol version is >>> TLS 1.3 >>> or later, that would imply that the new Finished computation >>> should be >>> used). >>> >>> 3. The specifications could require an explicit signal only for >>> implementations that don't announce TLS 1.3+ (i.e., if the >>> *requested* >>> protocol version is TLS 1.3+, that would imply that the new Finished >>> computation should be used). >>> >>> Stefan's proposal in the original message, it seems, was the third >>> variant. David's comment suggested that because of the complexity >>> that >>> comes with that variant, we should stick to the first one (and >>> always >>> keep signaling). >>> >>> That's not implied, though. The second variant makes a lot of >>> sense to >>> me -- it's just not something that the current specification would >>> or >>> should have to say a final word on: that's best left to the TLS 1.3 >>> specification. >> >> No, we have to decide now. For approach 2 to work, *every* patched >> implementation must know that requesting TLS 1.3+ implies that a >> client is patched. For approach 3 to work, *every* patched >> implementation >> must know that negotiating TLS 1.3+ implies that a server is patched. > > Correction: > For approach 3 to work, *every* patched implementation must know that > requesting TLS 1.3+ implies that a client is patched. > >> If we leave it until TLS 1.3 is specified, then there will exist >> implementations that don't know these things. Therefore, TLS 1.3+ >> clients >> will have to send the c->s signal anyway, in case the server is one >> of >> those that doesn't know that a TLS 1.3+ request implies that it is >> OK to >> send the s->c signal. Similarly, TLS 1.3+ servers will have to send >> the s->c signal anyway, in case the client is one of those that >> doesn't >> know that negotiating TLS 1.3+ implies being patched. > > The second part of this is wrong: TLS 1.3+ can be negotiated only > if the client supports it, therefore it can be assumed that the client > knows that negotiating TLS 1.3+ implies being patched. > > However, the first part was correct. So, "not deciding" is effectively > equivalent to deciding against approach 3 (and also against a > combination > of 2 and 3), while still leaving the choice between 1 and 2 open. Yes. That's exactly what I meant: The arguments against approach 3 don't imply that we should be using approach 1 -- but only the TLS 1.3 specification will really have to decide between approach 1 and approach 2. Bodo From stefan@aaa-sec.com Sun Nov 29 08:30:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDE83A6952 for ; Sun, 29 Nov 2009 08:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tnkgbNeE7M7 for ; Sun, 29 Nov 2009 08:30:41 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 9A7643A681B for ; Sun, 29 Nov 2009 08:30:40 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id AC6A428E2C4 for ; Sun, 29 Nov 2009 17:30:14 +0100 (CET) Received: (qmail 8445 invoked from network); 29 Nov 2009 16:30:08 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Nov 2009 16:30:08 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sun, 29 Nov 2009 17:30:07 +0100 From: Stefan Santesson To: Geoffrey Keating , Message-ID: Thread-Topic: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt Thread-Index: AcpxETYhemhxz3+oVUWSjO+HJ1AIVQ== In-Reply-To: <59FE2EFB-F8EC-489D-AFCE-3D3C29291ADF@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 16:30:43 -0000 Geoffery, The current version of this draft is: http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 It does no longer have the sections you refer to. /Stefan On 09-11-29 4:27 AM, "Geoffrey Keating" wrote: > Apple supports this draft, with the following modification: > > The draft does not address the security issue for existing clients unless it > requires that renegotiation occur only when the extension is present. I > suggest strengthening the language in 4.2 to read > > To prevent such attacks, servers MUST NOT allow clients who do not offer the > "renegotiation_info" extension to complete a renegotiation. If the client > initiated the renegotiation the server SHOULD respond to such requests with a > "no_renegotiation" alert [RFC 5246 requires this alert to be at the "warning" > level.] If the server initiated the renegotiation the fatal > "handshake_failure" alert is appropriate. > > and delete the sentence 'Servers SHOULD follow this behaviour'. > > With this modification, section 4.1.1 is redundant and may be deleted. It is > also possible to delete section 4.3 as with this modification, if the client > is convinced to drop the extension, either servers support the draft and will > refuse to renegotiate without the extension and are still secure, or don't > support the draft and will ignore the extension, and so would be insecure > anyway. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mike-list@pobox.com Sun Nov 29 09:02:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D0D3A68C8 for ; Sun, 29 Nov 2009 09:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 VOvc9xOxTRoI for ; Sun, 29 Nov 2009 09:02:01 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id D98E43A67FD for ; Sun, 29 Nov 2009 09:01:59 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B0D7EA2E46 for ; Sun, 29 Nov 2009 12:01:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=7Qpt/+lsN1t8 HHs0rLlH7m/gaeU=; b=KNEL0Wj+53H+ToGgOj6Ume5pHWFoNc+eN0WDq9OZDXew qJUHh1jWjiynmPQmSv0UPTzO+/GydAR9Ra4ZUQYsrBLzkJ7oUZWAJOMw/YmI3RRB nPf+ogHqSMr+BLJPhq3zoFMQuY1EGuw25jMfRUy3dkSmYQ2HwoHpidW/kNKsqOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=hGqQfX 5G3jT6UbUP7WmrCwKc5puFSlKGO1PyTS/Z2sIhstgyBDYYEW9Lf5fKIfAnJEnc0/ XljN7hHfc01FeBB+kl0bAnyrWItNtkIA9sJ0CSm0d41BvJzg/6OD6Pr1/gdXKVx5 p70hNQYzrhVB3xiw/RyYCFIylJL8S7G5fI/YM= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AC0FEA2E45 for ; Sun, 29 Nov 2009 12:01:52 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 20DFFA2E44 for ; Sun, 29 Nov 2009 12:01:51 -0500 (EST) Message-ID: <4B12A95E.6040402@pobox.com> Date: Sun, 29 Nov 2009 09:03:26 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> <4B117AF2.20703@pobox.com> <4B11C156.7060204@jacaranda.org> <4B11FBF8.8080400@pobox.com> <4B1205AC.3060106@jacaranda.org> In-Reply-To: <4B1205AC.3060106@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E440A948-DD08-11DE-849E-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:02:02 -0000 David-Sarah Hopwood wrote: > Michael D'Errico wrote: >> David-Sarah Hopwood wrote: >>> Michael D'Errico wrote: >>>> David-Sarah Hopwood wrote: > [...] >>>>> That potential weakness can be avoided by encoding the data to be added >>>>> into the hash as follows: >>>>> >>>>> struct { >>>>> enum { fake_finished(20) } fake_handshake_type; >>>>> enum { zero(0), (2^24-1) } fake_length; >>>>> opaque previous_client_verify_data<12..255>; >>>>> opaque previous_server_verify_data<12..255>; >>>>> } PreviousVerifyData; >>>> I like the direction this is going, but think that using a length of >>>> zero doesn't quite patch the potential weakness. >>> It does: as I said, for an implementation to be vulnerable it would >>> have to violate two existing 'MUST's -- failing to abort the handshake >>> on an out-of-order handshake message, and failing to check the >>> correctness of the verify_data in a Finished message. If it gets the >>> latter wrong, then it's clearly insecure anyway. What is sent after >>> the fake Finished message doesn't matter for avoiding this weakness. >> The theoretical weakness, as I understand it, is that inserting the >> previous verify_data directly into the handshake message stream would >> allow an attacker to send the previous data to an unpatched peer at the >> point where it would get inserted by a patched peer. If (and it's a >> big if) that peer ignores that data, then the handshake has the possibility >> of completing. > > The problem was that it wasn't possible to infer from the spec that > any possible extra handshake message at that point would cause an abort. > For the Finished message, it is possible to infer that it will. > >> Your fix is to insert a "fake" header in front of the verify_data to make >> the attack impossible. The problem with using a zero length is that the >> 4-byte header you inserted is a _valid zero-length Finished message_. > > No, a valid Finished message would have to include a verify_data hash > (36 bytes in SSLv3; 12 bytes or more in TLS). It isn't plausible to > suppose that an implementation that is secure in other respects would > just ignore an extra Finished message of the wrong length and not > containing the right hash. I meant "well-formed", not valid, sorry. It is plausible to think that a peer might ignore an empty Finished message, if you believe it can be broken in the way that would allow the theoretical attack to succeed. Making the "fake_length" extend beyond the end of the PreviousVerifyData completely solves this since it would cause the peer to read parts of the subsequent valid messages into the fake Finished message. Thus the Certificate message would be lost, making it impossible for the handshake to succeed. And if that doesn't convince you, would you agree that changing the length wouldn't hurt anything? If so, then you can appease me by making it 0xFFFFFF instead of zero. Mike From mike-list@pobox.com Sun Nov 29 09:08:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07773A6946 for ; Sun, 29 Nov 2009 09:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 rS9UW-KI5Ols for ; Sun, 29 Nov 2009 09:08:44 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 58D263A6962 for ; Sun, 29 Nov 2009 09:08:43 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 00AA8A2E9B for ; Sun, 29 Nov 2009 12:08:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=FQ1PgiyP2aG2 KPzQu3NHIHevvJE=; b=JJIIxIE6+foNRB9JBf5MV4qWczJhhlHXzBTKZMAWFGyA kvPdPtyXgZlS22P6DRjybt78oaB6K/ngfHHJLnMv2p/0u5Gu1ZnSD1VNiRR0r4yC jZTITRJy3hb/LXLk0iVWkbarKVhES4hm8QxJsKWUMN0zbbtFF3ATixwCXy4LjL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=fdzIOV b1Dws7hmNu8+mXLQX+kmHFJmZJXTBZzAM6EodRLJrmJqn0A1xjg8o4xzUoplbYIK t9mMDIOtjnmZUYnJROiPKhdSC5cFxacUpQ/APKHrSm5fr2E5OyQ0QKkrPl3LTfWI LUFVcYL92YlLOS2tD28s3cP6+guJk9D7ez3io= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id F0AEDA2E9A for ; Sun, 29 Nov 2009 12:08:36 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 4C7F7A2E99 for ; Sun, 29 Nov 2009 12:08:35 -0500 (EST) Message-ID: <4B12AAF6.7060203@pobox.com> Date: Sun, 29 Nov 2009 09:10:14 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D53912F4-DD09-11DE-AA6E-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:08:45 -0000 Bodo Moeller wrote: > On Nov 28, 2009, at 9:41 AM, David-Sarah Hopwood wrote: >> >> struct { >> enum { fake_finished(20) } fake_handshake_type; >> enum { zero(0), (2^24-1) } fake_length; >> opaque previous_client_verify_data<12..255>; >> opaque previous_server_verify_data<12..255>; >> } PreviousVerifyData; >> > (Encoding the actual combined length of the previous_..._verify_data > fields seems simpler to analyze -- this still wouldn't be a valid > Finished message; or hash an empty Finished first, then a pseudo-message > containing the previous verify data. Of course, neither of this avoids > the potential problem with buggy receivers that ignore out-of-sequence > messages. That pseudo-message *could* use the Certificate type to > maximize the probability that buggy implementations will look at it and > stop [given that Certificate is expected at that point of the protocol], > but I guess that looks even weirder.) Encoding a longer length is even better since that will suck some of the real Certificate message into the fake Finished message, making it impossible for the handshake to complete. How much longer? Why not just use the maximum length of 0xFFFFFF? Mike From djhopwood@googlemail.com Sun Nov 29 14:06:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303633A69DA for ; Sun, 29 Nov 2009 14:06:48 -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 yVhGiPGo3CZY for ; Sun, 29 Nov 2009 14:06:47 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id BD5D23A69E8 for ; Sun, 29 Nov 2009 14:06:46 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so761787eyf.51 for ; Sun, 29 Nov 2009 14:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Y5S+ZI5GGv9OY0aQnPhq5EAxcRtAsr1r7elVbezTA3A=; b=SdesdFiPSjOGKblb/2/oHoA6JdzwaKf6FFgzzXSPwCYewOW9RWpk914pS+xEE6V1iy RPLDneFQyxm11e9G1UMIgWWtjKsiT2AqILBGjSdjoueJjDb/xNc1ap4kaMk8AoFv7shf SVJ2kLVE5nC0DRVzS4Psb4Rno94yMjkPDbr8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=KD5bX1UqP4goDdWKUzVL23FcEW9HB09fYFl/7EuoFIwyj+9/K3vUj3lCYh4GYyYz/K PKC7RCsLAjtwavKlZ+1AlOPdDtGAUK48Umd4YH4Ta9K8q5VUhucyN1Wzh7roGSUmBHKl YTuMsWOAWRnGHJDyWQrAqoavv/aJxUF3jO+X4= Received: by 10.216.89.85 with SMTP id b63mr1210411wef.175.1259532396802; Sun, 29 Nov 2009 14:06:36 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id i34sm1610095gve.21.2009.11.29.14.06.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 29 Nov 2009 14:06:35 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B12F056.8060904@jacaranda.org> Date: Sun, 29 Nov 2009 22:06:14 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> <4B117AF2.20703@pobox.com> <4B11C156.7060204@jacaranda.org> <4B11FBF8.8080400@pobox.com> <4B1205AC.3060106@jacaranda.org> <4B12A95E.6040402@pobox.com> In-Reply-To: <4B12A95E.6040402@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE5C6336D2FCCBE39C174EA88" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 22:06:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5C6336D2FCCBE39C174EA88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > David-Sarah Hopwood wrote: >> No, a valid Finished message would have to include a verify_data hash >> (36 bytes in SSLv3; 12 bytes or more in TLS). It isn't plausible to >> suppose that an implementation that is secure in other respects would >> just ignore an extra Finished message of the wrong length and not >> containing the right hash. >=20 > I meant "well-formed", not valid, sorry. It is plausible to think that= > a peer might ignore an empty Finished message, if you believe it can be= > broken in the way that would allow the theoretical attack to succeed. >=20 > Making the "fake_length" extend beyond the end of the PreviousVerifyDat= a > completely solves this since it would cause the peer to read parts of > the subsequent valid messages into the fake Finished message. Thus the= > Certificate message would be lost, making it impossible for the handsha= ke > to succeed. >=20 > And if that doesn't convince you, would you agree that changing the len= gth > wouldn't hurt anything? If so, then you can appease me by making it > 0xFFFFFF instead of zero. I have no problem with this. By all means make it 0xFFFFFF. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigE5C6336D2FCCBE39C174EA88 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksS8GEACgkQWUc8YzyzqAdwegEAmJVTOFK15vDyFqk6wUDZaCFo onVGOha3Ed+s6Zp9wQ8A/0jXdRzE+BMgxycZEkbKEKZka8kSYaqK0p6oJ/Avax8R =lllk -----END PGP SIGNATURE----- --------------enigE5C6336D2FCCBE39C174EA88-- From benl@google.com Sun Nov 29 16:08:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA803A68C7 for ; Sun, 29 Nov 2009 16:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 zBFovVXU+zsC for ; Sun, 29 Nov 2009 16:08:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id D4D133A67A1 for ; Sun, 29 Nov 2009 16:08:33 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id nAU08PKN003960 for ; Mon, 30 Nov 2009 00:08:25 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259539706; bh=S3V0tW2QbyYZY5SPAaW3plLWi6w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=dxVSH4iujfEEcr4tsvkilq8nw/8CwCXD7XgZ59OM8zYerhhAB4tjcoxi2ag8KKUgV yQEAkRRRyr/Bbucbf6DiA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=a7Dm+WzIBNydYt8Yg5npCaDbL2hRYHkDlgIU0qIDNpZtVyianehxyu12VpihFvqlO gW63Hlz8VEDqixanKQpXw== Received: from yxe33 (yxe33.prod.google.com [10.190.2.33]) by wpaz33.hot.corp.google.com with ESMTP id nAU08LAh025265 for ; Sun, 29 Nov 2009 16:08:22 -0800 Received: by yxe33 with SMTP id 33so2803599yxe.0 for ; Sun, 29 Nov 2009 16:08:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.162.24 with SMTP id k24mr5997687ybe.98.1259539701667; Sun, 29 Nov 2009 16:08:21 -0800 (PST) In-Reply-To: References: <59FE2EFB-F8EC-489D-AFCE-3D3C29291ADF@apple.com> Date: Sun, 29 Nov 2009 16:08:21 -0800 Message-ID: <1b587cab0911291608u2de654a4vf95dc9ff601dbdbb@mail.gmail.com> From: Ben Laurie To: Stefan Santesson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Geoffrey Keating , tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 00:08:35 -0000 In 4, this says "Servers MUST treat receipt of TLS_RENEGO_PROTECTION_REQUEST exactly as if the client had sent an empty "renegotiation_info" extension" - presumably not _exactly_ - the hash calculation is different, right? In 5, "TLS clients which support this draft MUST generate either the"renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST cipher suite with every ClientHello" - because TLS_RENEGO_PROTECTION_REQUEST is equivalent to an empty extension it can only be used in the first ClientHello. 6.1, " However, it is expected that many TLS servers that do not support renegotiation (and thus are not vulnerable) will not support this extension either, so in general, such behavior would not work well." is pretty feeble - what do we suggest clients do in this case? Yeah, I've heard that some people don't want to change their implementations - so what? If they want to be nonconformant, that's their choice - we should not be encouraging that choice, though. 6.2 "In order to enable clients to probe, even servers which do not support renegotiation SHOULD implement the minimal version of the extension described in this document for initial handshakes, thus signalling that they have been upgraded." - SHOULD should be MUST. https://mail.google.com/mail/?zx=3D16yvh4iv244dd&shva=3D1#vftt_inbox/125139= 61f5f15eea On Sun, Nov 29, 2009 at 8:30 AM, Stefan Santesson wrot= e: > Geoffery, > > The current version of this draft is: > http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 > It does no longer have the sections you refer to. > > /Stefan > > > On 09-11-29 4:27 AM, "Geoffrey Keating" wrote: > >> Apple supports this draft, with the following modification: >> >> The draft does not address the security issue for existing clients unles= s it >> requires that renegotiation occur only when the extension is present. = =A0I >> suggest strengthening the language in 4.2 to read >> >> To prevent such attacks, servers MUST NOT allow clients who do not offer= the >> "renegotiation_info" extension to complete a renegotiation. =A0If the cl= ient >> initiated the renegotiation the server SHOULD respond to such requests w= ith a >> "no_renegotiation" alert [RFC 5246 requires this alert to be at the "war= ning" >> level.] =A0If the server initiated the renegotiation the fatal >> "handshake_failure" alert is appropriate. >> >> and delete the sentence 'Servers SHOULD follow this behaviour'. >> >> With this modification, section 4.1.1 is redundant and may be deleted. = =A0It is >> also possible to delete section 4.3 as with this modification, if the cl= ient >> is convinced to drop the extension, either servers support the draft and= will >> refuse to renegotiate without the extension and are still secure, or don= 't >> support the draft and will ignore the extension, and so would be insecur= e >> anyway. >> _______________________________________________ >> 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 marsh@extendedsubset.com Sun Nov 29 16:14:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76633A69F8 for ; Sun, 29 Nov 2009 16:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 CLqMsOettEAO for ; Sun, 29 Nov 2009 16:14:49 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 2DFD63A67A1 for ; Sun, 29 Nov 2009 16:14:49 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NEtuc-000LRL-5a; Mon, 30 Nov 2009 00:14:42 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 6171D603C; Mon, 30 Nov 2009 00:14:39 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18CFRQppFiFu0jXo3br/j5rBW05SyPl8ms= Message-ID: <4B130E65.4000009@extendedsubset.com> Date: Sun, 29 Nov 2009 18:14:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 00:14:52 -0000 Stefan Santesson wrote: > > The real security advantage of implicit is that you know that the opponent I agree that is possibly an advantage, but a very weak advantage. > actually derived the same value from previous handshake. By sending it in RI > you don't know if the opponent just blindly accepted what you sent without > checking it. By that logic, how do you know that he's checking the Finished message hash? - Marsh From marsh@extendedsubset.com Sun Nov 29 16:20:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9DD3A6A05 for ; Sun, 29 Nov 2009 16:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 IWQi1h7X2gph for ; Sun, 29 Nov 2009 16:20:42 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id AB1403A6A04 for ; Sun, 29 Nov 2009 16:20:42 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NEu0J-000ND1-Mo; Mon, 30 Nov 2009 00:20:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 761B3603C; Mon, 30 Nov 2009 00:20:34 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18OvNSpTm7fj2oN8ZE/wOH6uzoszrhqJkE= Message-ID: <4B130FC8.1050905@extendedsubset.com> Date: Sun, 29 Nov 2009 18:20:24 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bodo Moeller References: <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com> <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com> <4B0D5EF3.3020905@extendedsubset.com> <20091125165522.A2CDA6C3173@kilo.networkresonance.com> <808FD6E27AD4884E94820BC333B2DB774F310FE976@NOK-EUMSG-01.mgdnok.nokia.com> <79D75A57-260E-4ECC-90FF-9EB3B9B99F66@acm.org> In-Reply-To: <79D75A57-260E-4ECC-90FF-9EB3B9B99F66@acm.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] some questions for your draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 00:20:43 -0000 Bodo Moeller wrote: > On Nov 25, 2009, at 9:02 PM, > wrote: > >> While the RI extension fixes the man-in-the-middle problem, it doesn't >> remove the problems when there is no man-in-the-middle, just the two >> endpoints (either of whom could be potentially malicious). > > Why do you think so? > > If an RI-secured renegotiation shows a new certificate, this confirms > that the same party is using those two certificates. How could an > additional (potentially malicious) party join the conversation? I've been wondering that, too. What exactly is this defending against? What is a (properly-authenticated) "malicious endpoint", and how could a wire protocol defend against one? - Marsh From geoffk@apple.com Sun Nov 29 19:47:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D316C3A680E for ; Sun, 29 Nov 2009 19:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 CZf3EkMwxq4j for ; Sun, 29 Nov 2009 19:47:12 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 22C503A67AB for ; Sun, 29 Nov 2009 19:47:12 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 929DC7B27A5C; Sun, 29 Nov 2009 19:47:05 -0800 (PST) X-AuditID: 1180711d-b7b18ae000001001-86-4b134038bc42 Received: from [17.151.90.42] (Unknown_Domain [17.151.90.42]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 0A.45.04097.930431B4; Sun, 29 Nov 2009 19:47:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoffrey Keating In-Reply-To: Date: Sun, 29 Nov 2009 19:47:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <991C04C4-9F67-4CD5-A3EC-25AC8176F389@apple.com> References: To: Stefan Santesson X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 03:47:12 -0000 On 29/11/2009, at 8:30 AM, Stefan Santesson wrote: > Geoffery, >=20 > The current version of this draft is: > http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 > It does no longer have the sections you refer to. The sections were reorganised for the -01 version, so in that version = it's 6.2 that I suggest strengthening and section 4 that becomes = redundant and can be removed. > On 09-11-29 4:27 AM, "Geoffrey Keating" wrote: >=20 >> The draft does not address the security issue for existing clients = unless it >> requires that renegotiation occur only when the extension is present. = I >> suggest strengthening the language in 4.2 to read >>=20 >> To prevent such attacks, servers MUST NOT allow clients who do not = offer the >> "renegotiation_info" extension to complete a renegotiation. If the = client >> initiated the renegotiation the server SHOULD respond to such = requests with a >> "no_renegotiation" alert [RFC 5246 requires this alert to be at the = "warning" >> level.] If the server initiated the renegotiation the fatal >> "handshake_failure" alert is appropriate. >>=20 >> and delete the sentence 'Servers SHOULD follow this behaviour'. >>=20 >> With this modification, section 4.1.1 is redundant and may be = deleted. From stefan@aaa-sec.com Sun Nov 29 23:12:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612153A6855 for ; Sun, 29 Nov 2009 23:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii+cWybI0lrF for ; Sun, 29 Nov 2009 23:12:21 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id DA4633A67E5 for ; Sun, 29 Nov 2009 23:12:20 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0D1FD290201 for ; Mon, 30 Nov 2009 08:11:11 +0100 (CET) Received: (qmail 27486 invoked from network); 30 Nov 2009 07:11:09 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Nov 2009 07:11:09 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 30 Nov 2009 08:11:07 +0100 From: Stefan Santesson To: Marsh Ray Message-ID: Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpxjEkkCD9RKdjXHUuj7LRC360noQ== In-Reply-To: <4B130E65.4000009@extendedsubset.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 07:12:25 -0000 On 09-11-30 1:14 AM, "Marsh Ray" wrote: > Stefan Santesson wrote: >> >> The real security advantage of implicit is that you know that the opponent > > I agree that is possibly an advantage, but a very weak advantage. > Well, It's not weak or strong in a cryptographic sense. The weakness is totally dependent on whether implementers get this right or not. The problem is that you can't tell whether they did since it doesn't show. If they get it right, there is no weakness, if some or any get it wrong, it may significantly reduce the value of this effort. With implicit, implementers can't get it wrong and still produce a valid finished message. I personally think this is a significant advantage. >> actually derived the same value from previous handshake. By sending it in RI >> you don't know if the opponent just blindly accepted what you sent without >> checking it. > > By that logic, how do you know that he's checking the Finished message hash? > That you never know, but he wouldn't be able to produce a valid Finished message unless he derived the accurate data from the previous handshake. /Stefan > - Marsh From ynir@checkpoint.com Sun Nov 29 23:55:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D42C3A6A16 for ; Sun, 29 Nov 2009 23:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 hDRzDWAxDDuK for ; Sun, 29 Nov 2009 23:55:35 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 933BA3A685A for ; Sun, 29 Nov 2009 23:55:35 -0800 (PST) X-CheckPoint: {4B137681-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1532429C012; Mon, 30 Nov 2009 09:55:23 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E9ED929C002; Mon, 30 Nov 2009 09:55:22 +0200 (IST) X-CheckPoint: {4B13767A-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAU7tKGo004722; Mon, 30 Nov 2009 09:55:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 30 Nov 2009 09:55:26 +0200 From: Yoav Nir To: Stefan Santesson Date: Mon, 30 Nov 2009 09:55:17 +0200 Thread-Topic: [TLS] Verify data in the RI extension? Thread-Index: AcpxknomZEvtivlZSFSF2Jd/vf2PtA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Verify data in the RI extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 07:55:36 -0000 On Nov 30, 2009, at 9:11 AM, Stefan Santesson wrote: >=20 >=20 >=20 > On 09-11-30 1:14 AM, "Marsh Ray" wrote: >=20 >> Stefan Santesson wrote: >>>=20 >>> The real security advantage of implicit is that you know that the oppon= ent >>=20 >> I agree that is possibly an advantage, but a very weak advantage. >>=20 >=20 > Well, It's not weak or strong in a cryptographic sense. The weakness is > totally dependent on whether implementers get this right or not. The prob= lem > is that you can't tell whether they did since it doesn't show. > If they get it right, there is no weakness, if some or any get it wrong, = it > may significantly reduce the value of this effort. >=20 > With implicit, implementers can't get it wrong and still produce a valid > finished message. >=20 > I personally think this is a significant advantage. +1= From stefan@aaa-sec.com Mon Nov 30 05:56:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE073A6932 for ; Mon, 30 Nov 2009 05:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SawShFZyM28t for ; Mon, 30 Nov 2009 05:56:23 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 3A8313A6A62 for ; Mon, 30 Nov 2009 05:56:22 -0800 (PST) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0F68F28C5C2 for ; Mon, 30 Nov 2009 14:54:08 +0100 (CET) Received: (qmail 23293 invoked from network); 30 Nov 2009 13:54:03 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Nov 2009 13:54:03 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 30 Nov 2009 14:53:58 +0100 From: Stefan Santesson To: , Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: AcpvsK00o1AiVoleTQuKgrA4F9s+kwCE+L5j In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 13:56:24 -0000 Pasi, On 09-11-27 11:26 PM, "Pasi.Eronen@nokia.com" wrote: > I've gone through the list archives for the past month, and it seems a > large majority of the WG members support the overall approach in this > draft (with a small, but very vocal, minority preferring a totally > extension-less approach to signalling). I made a count through all people that has raised their voice on this list and included all e-mail that was sent the past week. I don't think it is fair to include any statements older than that. This is my count: Support an alternative solution: 6 people Open for an alternative solution: 3 people Neutral: 4 People Support the current tls draft: 7 people Conditional support for the current draft: 2 people Looks fairly even to me. /Stefan From wwwrun@core3.amsl.com Mon Nov 30 07:37:34 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D44C63A6AA9; Mon, 30 Nov 2009 07:37:34 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091130153734.D44C63A6AA9@core3.amsl.com> Date: Mon, 30 Nov 2009 07:37:34 -0800 (PST) Cc: tls@ietf.org Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 15:37:34 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19412&rfc_flag=0 From marsh@extendedsubset.com Mon Nov 30 08:32:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59083A6A9F for ; Mon, 30 Nov 2009 08:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 hYu-V8LCAEOD for ; Mon, 30 Nov 2009 08:32:24 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 7AE9B3A692F for ; Mon, 30 Nov 2009 08:31:55 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NF9AC-000A8Z-1T; Mon, 30 Nov 2009 16:31:48 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 910F8603C; Mon, 30 Nov 2009 16:31:46 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19d/MBorSBi4t9XUR18SkFYJELnCwbgepU= Message-ID: <4B13F367.6040307@extendedsubset.com> Date: Mon, 30 Nov 2009 10:31:35 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 References: <20091130153734.D44C63A6AA9@core3.amsl.com> In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:32:26 -0000 A few little suggestions, mostly wording. The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > > - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' > as a Proposed Standard http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 [Page 3] > renegotiation handshakes to the enclosing TLS channel, thus allowing > the server to differentiate renegotiation from initial negotiation, > as well as preventing renegotiations from being spliced in between > connections. "spliced in between sessions." [Page 5] > o For ClientHellos which are renegotiating, this field contains the "the renegotiated_connection field contains" [Page 6] > Both the SSLv3 and TLS 1.0/TLS1.1 specifications require > implementations to ignore data following the ClientHello (i.e., > extensions) if they do not understand it. However, some SSLv3 and > TLS 1.0 implementations incorrectly fail the handshake in such case. > This means that clients which offer "renegotiation_info" may find > handshake failures. In order to enhance compatibility with such > servers, this document defines a second signalling mechanism via a > special TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST", with code > point 0xNN, 0xMM. This cipher suite has exactly the same semantics > as an empty "renegotiation_info" extension. Because servers > ordinarily ignore unknown cipher suites, this cipher suite can be > added safely on any initial handshake, including SSLv2 backward > compatibility handshakes. > > Servers MUST treat receipt of TLS_RENEGO_PROTECTION_REQUEST exactly > as if the client had sent an empty "renegotiation_info" extension and > respond with their own "renegotiation_info" extension. This is an > explicit exception to the RFC 5246 Section 7.4.1.4 prohibition on the > server sending unsolicited extensions and is only allowed because the > client is signaling its willingness to receive the extension via the > the TLS_RENEGO_PROTECTION_REQUEST cipher suite. TLS implementations > MUST continue to comply with 7.4.1.4 for all other extensions. > Servers MUST NOT select this cipher suite in any handshake, as it > does not correspond to any valid set of algorithms. > > Because this cipher suite is equivalent to an empty > "renegotiation_info" extension, only renegotiation_info" may be used > rehandshakes. > > Note that a minimal client which does not support renegotiation at > all can simply use this cipher suite in all initial handshakes. Any > compliant server will reject any (apparent) attempt at renegotiation > by such a client. Clients which do support renegotiation MUST > implement Section 3 as well. I suggest we replace all uses of "cipher suite" in this section with the term "cipher suite value", and we add explicit wording "The TLS_RENEGO_PROTECTION_REQUEST cipher suite value is just a flag, it does not actually a refer to a set of cryptographic algorithms that could ever be used for data transmission." This might seem obvious to all of us, but this wording change could conceivably speed review and fend off questions by some review board. > TLS clients which support this draft MUST generate either the > > "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST > cipher suite with every ClientHello. Can they generate both? If not, what does the server do if he receives both? > Existing implementations which do not support this extension are > widely deployed and in general must interoperate with newer > implementations which do support it. This section describes s/must/need to/ to avoid confusion with MUST. > If a client offers the "renegotiation_info" extension or the > TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server does not > reply with "renegotiation_info" in the ServerHello, then this > indicates that the server either does not support secure > renegotiation or is unwilling to use it. Is it allowed for a patched server to be "unwilling"? If not, drop the "or is unwilling to use it" lest it give the impression that such behavior is condoned. > If the client does not offer the "renegotiation_info" extension or > the TLS_RENEGO_PROTECTION_REQUEST cipher suite then this indicates > that the client does not support secure renegotiation or is unwilling > to use it. However, because the above attack looks like two Again, is it allowed for a client to be conformant to this spec and still not send either the extension or magic cipher suite value? - Marsh From marsh@extendedsubset.com Mon Nov 30 08:35:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F0428C157 for ; Mon, 30 Nov 2009 08:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 valabmzRTnga for ; Mon, 30 Nov 2009 08:35:35 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 92C0528C155 for ; Mon, 30 Nov 2009 08:35:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NF9Dj-000FU0-TK for tls@ietf.org; Mon, 30 Nov 2009 16:35:28 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AC7C4603C for ; Mon, 30 Nov 2009 16:35:26 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ZhCezi122hnOp0onu18JuxyDQtb90k5M= Message-ID: <4B13F443.4060504@extendedsubset.com> Date: Mon, 30 Nov 2009 10:35:15 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Status of patches X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:35:36 -0000 A PhoneFactor, we're trying to do a service and maintain a status page for the various TLS implementations' fixes. http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches If you have any updates, or see anything we should, could you please drop me an email? It can be as general as "Yes, we have some experimental code". Thanks, - Marsh From marsh@extendedsubset.com Mon Nov 30 08:44:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19D93A6AB9 for ; Mon, 30 Nov 2009 08:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 4fbOudfW7RPS for ; Mon, 30 Nov 2009 08:44:32 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 109EB3A6AB8 for ; Mon, 30 Nov 2009 08:44:32 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NF9MO-000Jq1-7Z; Mon, 30 Nov 2009 16:44:24 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 79C1D603C; Mon, 30 Nov 2009 16:44:22 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19nez73mBnaMPopEh0C6v2OVaAlAO+PuTM= Message-ID: <4B13F65B.40204@extendedsubset.com> Date: Mon, 30 Nov 2009 10:44:11 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:44:32 -0000 Stefan Santesson wrote: > > This is my count: > > Support an alternative solution: 6 people > Open for an alternative solution: 3 people > Neutral: 4 People > Support the current tls draft: 7 people > Conditional support for the current draft: 2 people Please put me down in support of draft-ietf-tls-renegotiation-01 - Marsh From mike-list@pobox.com Mon Nov 30 08:56:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921173A6899 for ; Mon, 30 Nov 2009 08:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 raGNAHYUQ5JY for ; Mon, 30 Nov 2009 08:56:42 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 92FFB28C135 for ; Mon, 30 Nov 2009 08:56:42 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 25B4F84A76 for ; Mon, 30 Nov 2009 11:56:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Nun+4OwhTAvq 1c6WYwVN+5k24Mk=; b=msn7osAB1LumnQpyVhQDhNwLmjYNUeOYtFHFspQjXKXO xBp2EwyMpUfHtahElIkzAFipIFGOPGZ9PduPLsFM22TBd961GYfsGv4Odgz5YIJE IbwmxVSq1YPIg+NHGhs0Qzp5rBD/S2GdWSXcqBBPmQP+MkuQU0BpqI53bt/svQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=V5mnj+ 0YlEwrN6qPwzNqbSM8mdO6rc+kLoNmptnBwa0jiHM3QdYz9BHn6XzX5pu+gSOHK2 ztgfAszAW0MrbeQ0PcIoK1mmahRPE6TTlMY2tB5oZNBxSODkVsJcHaSNmzUq3vW4 gOAE6kqggn1lrrRLmE9BQT+xKUI3ic8WSKFgA= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1D74184A74 for ; Mon, 30 Nov 2009 11:56:35 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C90AF84A73 for ; Mon, 30 Nov 2009 11:56:34 -0500 (EST) Message-ID: <4B13F9AA.6020905@pobox.com> Date: Mon, 30 Nov 2009 08:58:18 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B13F65B.40204@extendedsubset.com> In-Reply-To: <4B13F65B.40204@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 51611CF6-DDD1-11DE-B26B-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:56:43 -0000 One thing that you may have missed is that on a renegotiation handshake, the client and server need to pack the extension with the old verify data and extract what they received from their peer. This is unchanged from the original draft-rescorla-... That is a heavyweight use of extensions for any code that currently does not use them. I do not support forcing this complex change on a body of maintenance programmers who don't know much about TLS. Mike Marsh Ray wrote: > Stefan Santesson wrote: >> This is my count: >> >> Support an alternative solution: 6 people >> Open for an alternative solution: 3 people >> Neutral: 4 People >> Support the current tls draft: 7 people >> Conditional support for the current draft: 2 people > > Please put me down in support of draft-ietf-tls-renegotiation-01 > > - Marsh From rdugal@certicom.com Mon Nov 30 09:15:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D2B28C16A; Mon, 30 Nov 2009 09:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 SF81J9SYXsCL; Mon, 30 Nov 2009 09:15:45 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id CF8CD28C167; Mon, 30 Nov 2009 09:15:44 -0800 (PST) X-AuditID: 0a666446-b7beeae0000071a4-41-4b13fdb808de Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 91.9A.29092.8BDF31B4; Mon, 30 Nov 2009 12:15:37 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 12:15:36 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Mon, 30 Nov 2009 12:15:38 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4028472C6@XCH57YKF.rim.net> In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard Thread-Index: Acpx01KW4vupGUWDS4aFcmDgcLATCgADLHcg References: <20091130153734.D44C63A6AA9@core3.amsl.com> From: "Robert Dugal" To: X-OriginalArrivalTime: 30 Nov 2009 17:15:36.0575 (UTC) FILETIME=[BB7EE8F0:01CA71E0] X-Brightmail-Tracker: AAAAAwAAAZER3/EWEd/xFw== Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:15:46 -0000 I support draft-ietf-tls-renegotiation-01.txt. -- Robert Dugal Senior Software Developer Certicom Corp. A Subsidiary of Research In Motion rdugal@certicom.com direct=A0=A0=A0=A0=A0=A0=A0=A0905.501.3848 fax=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0905.507.4230 www.certicom.com -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of The IE= SG Sent: Monday, November 30, 2009 10:38 AM To: IETF-Announce Cc: tls@ietf.org Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecur= ity (TLS) Renegotiation Indication Extension) toProposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=3D= 19412&rfc_flag=3D0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From Nicolas.Williams@sun.com Mon Nov 30 09:19:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEA13A6AD7 for ; Mon, 30 Nov 2009 09:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.842 X-Spam-Level: X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.204, 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 LFY3lyo7ku97 for ; Mon, 30 Nov 2009 09:19: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 2FD3C3A6AD6 for ; Mon, 30 Nov 2009 09:19: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 nAUHJUhw022004 for ; Mon, 30 Nov 2009 17:19:30 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 nAUHJTwv049493 for ; Mon, 30 Nov 2009 10:19:29 -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 nAUH7kF7006790; Mon, 30 Nov 2009 11:07:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAUH7jl6006789; Mon, 30 Nov 2009 11:07:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Nov 2009 11:07:45 -0600 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20091130170745.GH773@Sun.COM> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:19:42 -0000 On Fri, Nov 27, 2009 at 11:26:34PM +0100, Pasi.Eronen@nokia.com wrote: > > > I have asked the secretariat to start IETF Last Call for > draft-rescorla-tls-renegotiation-01. > > I've gone through the list archives for the past month, and it seems a > large majority of the WG members support the overall approach in this > draft (with a small, but very vocal, minority preferring a totally > extension-less approach to signalling). I don't think that's a fair nor complete characterization of the current differences of opinion. A more complete and correct characterization might be: - The RI proposal has a fail-unsafe requirement that peers check the contents of the extensions sent. NOTE: A fix for this wouldn't require an extension-less signalling solution. [IMO: This is serious objection that goes beyond protocol design aesthetics or ease of retrofitting for SSLv3. I think we can live without a fix for this problem, but I'd much rather have a fail-safe solution.] - There seems to be a desire, among some, for a signalling solution that is somehow easier to retrofit for SSLv3 implementations. This couldn't be an extension-less scheme, since some bits are needed to signal the use of the fix in the client's initial hello, but it might avoid the use of server hello extensions. [IMO: This is a concern that we can safely ignore.] Nico -- From Michael.Tuexen@lurchi.franken.de Mon Nov 30 09:38:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA8028C11F for ; Mon, 30 Nov 2009 09:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ-aOqBBXKRk for ; Mon, 30 Nov 2009 09:38:50 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 4E6493A6959 for ; Mon, 30 Nov 2009 09:38:50 -0800 (PST) Received: from [IPv6:2002:508f:ce17::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:ce17:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id DFCB41C0B404A for ; Mon, 30 Nov 2009 18:38:41 +0100 (CET) From: =?iso-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 30 Nov 2009 18:38:41 +0100 Message-Id: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:38:51 -0000 Dear all, I would like to get the relation of the RI Extension and DTLS clarified. If I'm not wrong, then the attack which works against TLS does not work against DTLS, since DTLS has an epoch counter. If a client tries to establish a DTLS connection and a MITM intercepts it, establishes itself a DTLS connection, the epoch is 1. There will be a final mismatch in the epoch and the packets will be discarded. When using the RI extension one could enforce the sending of the alert message. But the original attack is not possible, I think. Is my analysis correct or am I overlooking something? If I'm right, is the alert worth using the RI also for DTLS? Can we add a statement to draft-ietf-tls-renegotiation-01.txt clearly stating that the RI MUST also be used for DTLS or MUST NOT be used. Best regards Michael From stefan@aaa-sec.com Mon Nov 30 09:55:42 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B0128C0D8 for ; Mon, 30 Nov 2009 09:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8K63Fl6PyaY9 for ; Mon, 30 Nov 2009 09:55:41 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 6E3603A6916 for ; Mon, 30 Nov 2009 09:55:41 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2AB3C29157B for ; Mon, 30 Nov 2009 18:55:38 +0100 (CET) Received: (qmail 85486 invoked from network); 30 Nov 2009 17:55:30 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Nov 2009 17:55:30 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 30 Nov 2009 18:55:26 +0100 From: Stefan Santesson To: Nicolas Williams , Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acpx5ku0b1RRqfqKEEmqAoMecVQ0gA== In-Reply-To: <20091130170745.GH773@Sun.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:55:42 -0000 Nico, I think your characterization is very good. And I would also much rather have a fail-safe solution. As you say, no approach today is totally extension less, so the big difference remaining IMO is: 1) The fail-unsafe approach based on sending verify_data in extensions. 2) The Fail-safe approach based on injecting varify_data into the handshake hash calculation, but not sending them over the wire. (This approach uses extensions for signaling but with absent data) Everything else is more or less the same. I think we have demonstrated that the fail-safe alternative can be designed in a secure manner. /Stefan On 09-11-30 6:07 PM, "Nicolas Williams" wrote: > On Fri, Nov 27, 2009 at 11:26:34PM +0100, Pasi.Eronen@nokia.com wrote: >> >> >> I have asked the secretariat to start IETF Last Call for >> draft-rescorla-tls-renegotiation-01. >> >> I've gone through the list archives for the past month, and it seems a >> large majority of the WG members support the overall approach in this >> draft (with a small, but very vocal, minority preferring a totally >> extension-less approach to signalling). > > I don't think that's a fair nor complete characterization of the current > differences of opinion. A more complete and correct characterization > might be: > > - The RI proposal has a fail-unsafe requirement that peers check the > contents of the extensions sent. > > NOTE: A fix for this wouldn't require an extension-less signalling > solution. > > [IMO: This is serious objection that goes beyond protocol design > aesthetics or ease of retrofitting for SSLv3. I think we can > live without a fix for this problem, but I'd much rather have a > fail-safe solution.] > > - There seems to be a desire, among some, for a signalling solution > that is somehow easier to retrofit for SSLv3 implementations. This > couldn't be an extension-less scheme, since some bits are needed to > signal the use of the fix in the client's initial hello, but it might > avoid the use of server hello extensions. > > [IMO: This is a concern that we can safely ignore.] > > Nico From marsh@extendedsubset.com Mon Nov 30 10:02:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8EA3A690B for ; Mon, 30 Nov 2009 10:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 Q+G9JShYr-IH for ; Mon, 30 Nov 2009 10:02:55 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id A9E643A63C9 for ; Mon, 30 Nov 2009 10:02:55 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NFAaG-0006YK-4C; Mon, 30 Nov 2009 18:02:48 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 59C45603C; Mon, 30 Nov 2009 18:02:45 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18A8oo6cAGZgOc8Gg0eym6sf9/2aucwlIA= Message-ID: <4B1408B9.4000707@extendedsubset.com> Date: Mon, 30 Nov 2009 12:02:33 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <4B13F65B.40204@extendedsubset.com> <4B13F9AA.6020905@pobox.com> In-Reply-To: <4B13F9AA.6020905@pobox.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:02:56 -0000 Michael D'Errico wrote: > One thing that you may have missed is that on a renegotiation > handshake, the client and server need to pack the extension with > the old verify data and extract what they received from their > peer. This is unchanged from the original draft-rescorla-... Yeah, I realize that. My thinking has personally been back and forth several times in the last few months. Now that I feel like I understand the issues involved a bit better, I have weighed them and feel that draft-ietf-renego-01 is the least disruptive and will be fastest to deploy. Although we would have all done it differently knowing what we know now, at this stage touching anything involving the hash calculations themselves brings along all sorts of baggage. It might trigger a formal cryptographic review in a lot of deployments. Comparing two hash values for equality is as lightweight a bugfix change as anyone's going to get. > That is a heavyweight use of extensions for any code that currently > does not use them. I do not support forcing this complex change on > a body of maintenance programmers who don't know much about TLS. A) I mean, come on people, if you can't implement that loop in software you're in the wrong business. > Thus, the entire encoding of the > extension is: ff 01 00 01 00. The first two octets represent the > extension type, the third and fourth octet the length of the > extension itself, and the final octet the zero length byte for the > "renegotiated_connection" field. This should not require adding general support for extensions to a public API. B) Everyone knows that this is a critical infrastructure component and companies will have skilled developers involved in all changes and lots of testing and review. Don't knock "maintenance programmers", they know better what can go wrong than the original implementors. - Marsh From marsh@extendedsubset.com Mon Nov 30 10:06:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4947828C161 for ; Mon, 30 Nov 2009 10:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 LrWqle1V6vcD for ; Mon, 30 Nov 2009 10:06:22 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 8AD583A6916 for ; Mon, 30 Nov 2009 10:06:22 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NFAdb-000C7l-6H; Mon, 30 Nov 2009 18:06:15 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id EFC7C603C; Mon, 30 Nov 2009 18:06:13 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ufCS0dBTSVg2jhnvSJEXOn+v8hFZPHTg= Message-ID: <4B14098A.9090801@extendedsubset.com> Date: Mon, 30 Nov 2009 12:06:02 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> In-Reply-To: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:06:23 -0000 Michael T=FCxen wrote: >=20 > If I'm not wrong, then the attack which works against TLS does not > work against DTLS, since DTLS has an epoch counter. >=20 > If a client tries to establish a DTLS connection and a MITM intercepts > it, establishes itself a DTLS connection, the epoch is 1. There will be > a final mismatch in the epoch and the packets will be discarded. When > using the RI extension one could enforce the sending of the alert messa= ge. > But the original attack is not possible, I think. >=20 > Is my analysis correct or am I overlooking something? Can MitM do the same number of renegotitations as he does with the server before splicing him? - Marsh From rwilliams@certicom.com Mon Nov 30 10:13:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA91F3A6983; Mon, 30 Nov 2009 10:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 3u7pvNpYL7gv; Mon, 30 Nov 2009 10:13:08 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 0FDCA3A697F; Mon, 30 Nov 2009 10:13:07 -0800 (PST) X-AuditID: 0a401fcb-b7b87ae000007a96-f1-4b140b2b3b1b Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id F4.F4.31382.B2B041B4; Mon, 30 Nov 2009 13:13:00 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 13:12:59 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Mon, 30 Nov 2009 13:12:59 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4029271F5@XCH57YKF.rim.net> In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard Thread-Index: Acpx01KW4vupGUWDS4aFcmDgcLATCgAFWfsA References: <20091130153734.D44C63A6AA9@core3.amsl.com> From: "Rob P Williams" To: , "IETF-Announce" X-OriginalArrivalTime: 30 Nov 2009 18:12:59.0534 (UTC) FILETIME=[BFA8C2E0:01CA71E8] X-Brightmail-Tracker: AAAAAwAAAZER3/EWEd/xFw== Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:13:09 -0000 I support this draft. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, November 30, 2009 10:38 AM To: IETF-Announce Cc: tls@ietf.org Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=3D 19412&rfc_flag=3D0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From aerowolf@gmail.com Mon Nov 30 10:19:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815A128C150 for ; Mon, 30 Nov 2009 10:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 vNd2LKmHc3oa for ; Mon, 30 Nov 2009 10:19:54 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 850F228C139 for ; Mon, 30 Nov 2009 10:19:54 -0800 (PST) Received: by pzk6 with SMTP id 6so2708658pzk.29 for ; Mon, 30 Nov 2009 10:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tt1dViH/h21xmWEIp6vnX2UtqF3KRg1/Yk7W2A/F/ck=; b=uXlbLKG5Ie5F2mWgk54d6rRfiIyQhXgPgvY4SKUUsnhzPASGipl85Iiz2AEAOwjYwg PeoRMU+rUym3zpjGO/LStjreyQGxwPmasbVzH4MCHwCJ+VABvxHnU+IYYImFjj+KfFz7 c0vrABnY0sXihv6MYCfy1jXhytsmnuicw3U/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=t/KDlNDNUCsNmK13aQe56B3iiL7ei59SfWUq3a3Ip1cf0XmXFjD5MfUYc47ShMVyc5 d4K+rVNYrPq1VcOrq74ialJx7Jy3o/K9ryJ/bLu3vibUFMMDnLX7RwMpuVCgTjUw+j7O +fZn49bniCrz/2mHchN1xli11dME3XjHrYOyk= MIME-Version: 1.0 Received: by 10.142.61.23 with SMTP id j23mr485104wfa.299.1259605185256; Mon, 30 Nov 2009 10:19:45 -0800 (PST) In-Reply-To: <4B13F367.6040307@extendedsubset.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> Date: Mon, 30 Nov 2009 10:19:45 -0800 Message-ID: <6b9359640911301019w114a2a46m32c16afb2cb26067@mail.gmail.com> From: Kyle Hamilton To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:19:55 -0000 What I'm seeing here: An implementation continues to be conformant to TLS even if the RI isn't sent. If a client doesn't send the RI (either cipher suite flag or extension), the server can't send the RI extension back (as it's a violation of TLS 1.2 for a server to send an unsolicited extension). If a client does send the RI cipherflag or extension, the server may send back the RI reply, or (if its security policy prohibits renegotiation -- to reduce the possible impact of large numbers of reneg's overwhelming any crypto implementation, or because it's known that client certificates are never going to be solicited by the server, to name a couple of possible reasons) it may choose not to reply with the extension. In the event that the RI client doesn't receive the extension that it solicited back from the server, it treats it as a non-RI server and proceeds according to its own security policy. (It goes without saying that the peers' security policies must have some compatibility -- FIPS 140-2 validated TLS implementations already can't talk to implementations that don't have any FIPS-approved algorithms, so there's no reason to worry about this.) On Mon, Nov 30, 2009 at 8:31 AM, Marsh Ray wrote= : > >> =C2=A0 =C2=A0TLS clients which support this draft MUST generate either t= he >> >> =C2=A0 =C2=A0"renegotiation_info" extension or the TLS_RENEGO_PROTECTION= _REQUEST >> =C2=A0 =C2=A0cipher suite with every ClientHello. > > Can they generate both? > > If not, what does the server do if he receives both? I suggest the wording 'MUST generate either or both of the RI extension or the TLS_RENEGO_PROTECTION_REQUEST cipher suite flag with every ClientHello. If the client requests renegotiation, it must do so with the same mechanism(s) that it used during the initial ClientHello -- e.g. if the client uses the RI extension without the cipher suite flag, then ClientHello handshake messages used for renegotiation must not contain the cipher suite flag.' >> =C2=A0 =C2=A0Existing implementations which do not support this extensio= n are >> =C2=A0 =C2=A0widely deployed and in general must interoperate with newer >> =C2=A0 =C2=A0implementations which do support it. =C2=A0This section des= cribes > > s/must/need to/ to avoid confusion with MUST. Agreed. > >> =C2=A0 =C2=A0If a client offers the "renegotiation_info" extension or th= e >> =C2=A0 =C2=A0TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server d= oes not >> =C2=A0 =C2=A0reply with "renegotiation_info" in the ServerHello, then th= is >> =C2=A0 =C2=A0indicates that the server either does not support secure >> =C2=A0 =C2=A0renegotiation or is unwilling to use it. > > Is it allowed for a patched server to be "unwilling"? > > If not, drop the "or is unwilling to use it" lest it give the impression > that such behavior is condoned. Above, I've suggested a couple of potential reasons why a server (which knows about the renegotiation security hole) might simply disable renegotiation entirely. >> =C2=A0 =C2=A0If the client does not offer the "renegotiation_info" exten= sion or >> =C2=A0 =C2=A0the TLS_RENEGO_PROTECTION_REQUEST cipher suite then this in= dicates >> =C2=A0 =C2=A0that the client does not support secure renegotiation or is= unwilling >> =C2=A0 =C2=A0to use it. =C2=A0However, because the above attack looks li= ke two > > Again, is it allowed for a client to be conformant to this spec and > still not send either the extension or magic cipher suite value? > > - Marsh A client may be conformant to this specification without sending either the RI ext or the cipher suite flag, if it knows that it will not perform or accept any requests to perform any renegotiations. If it does not, the server will believe that it is an unpatched client and expect/accept only one negotiation. Why indicate your willingness to do something that you're not willing to do later anyway? I'd suggest adding wording to this effect, suggesting that implementations SHOULD offer this extension only if they're willing to accept renegotiations. (Local security policies may include "all traffic that goes over the internet must appear as though it's coming from servers that will renegotiate" -- if only as a prophylactic against someone doing deep packet scanning and seeing a potentially insecure server for later attack attempts.) -Kyle H From Michael.Tuexen@lurchi.franken.de Mon Nov 30 10:23:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EACD28C11F for ; Mon, 30 Nov 2009 10:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WPt8rb7U9Ax for ; Mon, 30 Nov 2009 10:23:31 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 7C4803A6836 for ; Mon, 30 Nov 2009 10:23:31 -0800 (PST) Received: from [IPv6:2002:508f:ce17::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:ce17:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 024DE1C0B461B; Mon, 30 Nov 2009 19:23:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4B14098A.9090801@extendedsubset.com> Date: Mon, 30 Nov 2009 19:23:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> To: Marsh Ray X-Mailer: Apple Mail (2.1077) Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:23:32 -0000 On Nov 30, 2009, at 7:06 PM, Marsh Ray wrote: > Michael T=FCxen wrote: >>=20 >> If I'm not wrong, then the attack which works against TLS does not >> work against DTLS, since DTLS has an epoch counter. >>=20 >> If a client tries to establish a DTLS connection and a MITM = intercepts >> it, establishes itself a DTLS connection, the epoch is 1. There will = be >> a final mismatch in the epoch and the packets will be discarded. When >> using the RI extension one could enforce the sending of the alert = message. >> But the original attack is not possible, I think. >>=20 >> Is my analysis correct or am I overlooking something? >=20 > Can MitM do the same number of renegotitations as he does with the > server before splicing him? Good point, I missed that. So DTLS is also affected. Could we then make it clear the that the RI extension applies to TLS and DTLS? Best regards Michael >=20 > - Marsh >=20 >=20 From ekr@networkresonance.com Mon Nov 30 10:28:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC363A6838 for ; Mon, 30 Nov 2009 10:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b7-Xf1lVXSo for ; Mon, 30 Nov 2009 10:28:34 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id DE12528C134 for ; Mon, 30 Nov 2009 10:28:34 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 39B596C3EB8; Mon, 30 Nov 2009 10:29:31 -0800 (PST) Date: Mon, 30 Nov 2009 10:29:30 -0800 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B14098A.9090801@extendedsubset.com> References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20091130182931.39B596C3EB8@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:28:35 -0000 At Mon, 30 Nov 2009 12:06:02 -0600, Marsh Ray wrote: >=20 > Michael T=FCxen wrote: > >=20 > > If I'm not wrong, then the attack which works against TLS does not > > work against DTLS, since DTLS has an epoch counter. > >=20 > > If a client tries to establish a DTLS connection and a MITM intercepts > > it, establishes itself a DTLS connection, the epoch is 1. There will be > > a final mismatch in the epoch and the packets will be discarded. When > > using the RI extension one could enforce the sending of the alert messa= ge. > > But the original attack is not possible, I think. > >=20 > > Is my analysis correct or am I overlooking something? >=20 > Can MitM do the same number of renegotitations as he does with the > server before splicing him? Nagendray and I had this conversation last week. While I haven't done a complete analysis, my intuition is that DTLS is more resistant (for the reason you indicate) but not 100% resistant. Another concern would be epoch rollover: what if you do 65536 (65535?--too lazy to calculate) handshakes with the server and force the epoch back to 0? So, probably better to use RI with DTLS as well. -Ekr From ekr@networkresonance.com Mon Nov 30 10:29:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E8728C159 for ; Mon, 30 Nov 2009 10:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.204 X-Spam-Level: X-Spam-Status: No, score=0.204 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-wlDEB4PLiy for ; Mon, 30 Nov 2009 10:29:00 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 2AEB23A6838 for ; Mon, 30 Nov 2009 10:29:00 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id F3B846C3EB9; Mon, 30 Nov 2009 10:29:56 -0800 (PST) Date: Mon, 30 Nov 2009 10:29:56 -0800 From: Eric Rescorla To: Michael =?ISO-8859-1?Q?T=FCxen?= In-Reply-To: References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20091130182956.F3B846C3EB9@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:29:01 -0000 At Mon, 30 Nov 2009 19:23:22 +0100, Michael T=FCxen wrote: >=20 > On Nov 30, 2009, at 7:06 PM, Marsh Ray wrote: >=20 > > Michael T=FCxen wrote: > >>=20 > >> If I'm not wrong, then the attack which works against TLS does not > >> work against DTLS, since DTLS has an epoch counter. > >>=20 > >> If a client tries to establish a DTLS connection and a MITM intercepts > >> it, establishes itself a DTLS connection, the epoch is 1. There will be > >> a final mismatch in the epoch and the packets will be discarded. When > >> using the RI extension one could enforce the sending of the alert mess= age. > >> But the original attack is not possible, I think. > >>=20 > >> Is my analysis correct or am I overlooking something? > >=20 > > Can MitM do the same number of renegotitations as he does with the > > server before splicing him? > Good point, I missed that. So DTLS is also affected. >=20 > Could we then make it clear the that the RI extension applies to > TLS and DTLS? Yep. I'll add it to my TODO list. -Ekr From aerowolf@gmail.com Mon Nov 30 10:31:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46E53A68BA for ; Mon, 30 Nov 2009 10:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 YtwhBD5hCYlK for ; Mon, 30 Nov 2009 10:31:51 -0800 (PST) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by core3.amsl.com (Postfix) with ESMTP id 9541228C134 for ; Mon, 30 Nov 2009 10:31:51 -0800 (PST) Received: by pxi14 with SMTP id 14so2893294pxi.31 for ; Mon, 30 Nov 2009 10:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vLaQasDqdNBEL5DNvahF89DoybkHgaIhvvvGzNOYaf8=; b=UgJ2faFN7CBEChXgqScdyg+7AJCUfvEAolOZr5SAqOhc6SayqPJ3443Y0xRzlL9mz2 IsYsO6Sn/Ht8Hip6qVCrAI4JLCk9+YCnXoIwpa07IVKvC3J/vwU0FiEl7JOp9NJstqzE x5MGO9//AOp8uv6jfYxOUgZ4hl/xrYBc8K1/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i2/1dJrQ53ux/ChWxgQtTH4FwWUcaAfPosIvQRz/eMqlnkW7mVMYDT2lhpMQyN58XG hg3PhZdTrYyMJRrcCZa9Ae/BkEq3bOHF9O/dHWyz8p8zXQBxkOGMkKT38PKhxpxlyDIi j/JeHsQjpvarNYdtjIik0EZTgSOhm99cK8Nic= MIME-Version: 1.0 Received: by 10.142.60.11 with SMTP id i11mr476264wfa.270.1259605900251; Mon, 30 Nov 2009 10:31:40 -0800 (PST) In-Reply-To: <20091130182931.39B596C3EB8@kilo.networkresonance.com> References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> <20091130182931.39B596C3EB8@kilo.networkresonance.com> Date: Mon, 30 Nov 2009 10:31:40 -0800 Message-ID: <6b9359640911301031o435c8ae9w93ffffb8ac04353a@mail.gmail.com> From: Kyle Hamilton To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:31:56 -0000 I would support randomizing the epoch counter in DTLS, giving a 1:2^16 chance of getting it right in a single attempt. (This follows my observation that the hash saved from the last Finished message is essentially the same as a named epoch.) -Kyle H On Mon, Nov 30, 2009 at 10:29 AM, Eric Rescorla wrote: > At Mon, 30 Nov 2009 12:06:02 -0600, > Marsh Ray wrote: >> >> Michael T=C3=BCxen wrote: >> > >> > If I'm not wrong, then the attack which works against TLS does not >> > work against DTLS, since DTLS has an epoch counter. >> > >> > If a client tries to establish a DTLS connection and a MITM intercepts >> > it, establishes itself a DTLS connection, the epoch is 1. There will b= e >> > a final mismatch in the epoch and the packets will be discarded. When >> > using the RI extension one could enforce the sending of the alert mess= age. >> > But the original attack is not possible, I think. >> > >> > Is my analysis correct or am I overlooking something? >> >> Can MitM do the same number of renegotitations as he does with the >> server before splicing him? > > Nagendray and I had this conversation last week. While I haven't done > a complete analysis, my intuition is that DTLS is more resistant (for > the reason you indicate) but not 100% resistant. =C2=A0Another concern > would be epoch rollover: what if you do 65536 (65535?--too lazy to > calculate) handshakes with the server and force the epoch back to 0? > > So, probably better to use RI with DTLS as well. > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mrex@sap.com Mon Nov 30 10:47:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC6A3A6944 for ; Mon, 30 Nov 2009 10:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 vym5Io-s75IN for ; Mon, 30 Nov 2009 10:47:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 804053A684C for ; Mon, 30 Nov 2009 10:47:49 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAUIlepd017396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 19:47:40 +0100 (MET) From: Martin Rex Message-Id: <200911301847.nAUIldG5010270@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 30 Nov 2009 19:47:39 +0100 (MET) In-Reply-To: <20091130170745.GH773@Sun.COM> from "Nicolas Williams" at Nov 30, 9 11:07:45 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:47:50 -0000 Nicolas Williams wrote: > > On Fri, Nov 27, 2009 at 11:26:34PM +0100, Pasi.Eronen@nokia.com wrote: > > > > > > I have asked the secretariat to start IETF Last Call for > > draft-rescorla-tls-renegotiation-01. > > > > I've gone through the list archives for the past month, and it seems a > > large majority of the WG members support the overall approach in this > > draft (with a small, but very vocal, minority preferring a totally > > extension-less approach to signalling). > > I don't think that's a fair nor complete characterization of the current > differences of opinion. A more complete and correct characterization > might be: > > - The RI proposal has a fail-unsafe requirement that peers check the > contents of the extensions sent. > > NOTE: A fix for this wouldn't require an extension-less signalling > solution. > > [IMO: This is serious objection that goes beyond protocol design > aesthetics or ease of retrofitting for SSLv3. I think we can > live without a fix for this problem, but I'd much rather have a > fail-safe solution.] What makes me feel somewhat uncomfortable is the situation when the client is doing an initial handshake and the server is doing a renegotiation handshake: The client will send an emtpy extension. The server should abort. But if the server is a little sloppy, and sends back an empty extension in ServerHello (matching the empty extension received in ClientHello), then the handshake will succeed. In that case, the renegotiation vulnerability will be still present, but this will not be obvious in the regular interop-testing and the client has no way to detect that the server is goofing his job. The problem is, that it is so extremely easy for the server to goof his job. If we add the verify_data to the renegotiation and something small but different to the initial handshakes between updated server and updated client, then it will be extremely difficult to get it wrong and still interoperate -- it will be _much_ easier to interoperate hand have it correct. -Martin From marsh@extendedsubset.com Mon Nov 30 10:47:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25DA3A697F for ; Mon, 30 Nov 2009 10:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 ikfllnouD38L for ; Mon, 30 Nov 2009 10:47:51 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 43A1F3A6944 for ; Mon, 30 Nov 2009 10:47:51 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NFBHh-000Pzs-LS; Mon, 30 Nov 2009 18:47:43 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 34454603C; Mon, 30 Nov 2009 18:47:40 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/mx1HV1WcpxI2ftXZZZZNxCsFQG41umq4= Message-ID: <4B141340.9040706@extendedsubset.com> Date: Mon, 30 Nov 2009 12:47:28 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kyle Hamilton References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <6b9359640911301019w114a2a46m32c16afb2cb26067@mail.gmail.com> In-Reply-To: <6b9359640911301019w114a2a46m32c16afb2cb26067@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:47:52 -0000 Kyle Hamilton wrote: > What I'm seeing here: > > An implementation continues to be conformant to TLS even if the RI > isn't sent. Sure, but is it compliant with draft-ietf-tls-renegotiation? I suggest that it shouldn't be. > If a client doesn't send the RI (either cipher suite flag > or extension), the server can't send the RI extension back (as it's a > violation of TLS 1.2 for a server to send an unsolicited extension). > If a client does send the RI cipherflag or extension, the server may > send back the RI reply, or (if its security policy prohibits > renegotiation -- to reduce the possible impact of large numbers of > reneg's overwhelming any crypto implementation, or because it's known > that client certificates are never going to be solicited by the > server, to name a couple of possible reasons) it may choose not to > reply with the extension. What is the benefit to anyone of a patched server not replying with the extension when it was specifically requested by the client? Allowing that just adds (or multiplies) in another valid combination that has to be regression tested. > In the event that the RI client doesn't receive the extension that it > solicited back from the server, it treats it as a non-RI server and > proceeds according to its own security policy. Which a year from now ought to be "don't connect to servers who's admins don't care enough to apply security patches in a year". > (It goes without saying that the peers' security policies must have > some compatibility -- FIPS 140-2 validated TLS implementations already > can't talk to implementations that don't have any FIPS-approved > algorithms, so there's no reason to worry about this.) > > On Mon, Nov 30, 2009 at 8:31 AM, Marsh Ray wrote: >>> TLS clients which support this draft MUST generate either the >>> >>> "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST >>> cipher suite with every ClientHello. >> Can they generate both? >> >> If not, what does the server do if he receives both? > > I suggest the wording 'MUST generate either or both of the RI > extension or the TLS_RENEGO_PROTECTION_REQUEST cipher suite flag with > every ClientHello. Agreed. > If the client requests renegotiation, it must do > so with the same mechanism(s) that it used during the initial > ClientHello -- e.g. if the client uses the RI extension without the > cipher suite flag, then ClientHello handshake messages used for > renegotiation must not contain the cipher suite flag.' Why? What if the client used the MCS flag for the initial handshake? How can he send the verify_data if there's no RI in the second handshake? If it must be restricted, I'd prefer that the MCS flag be allowed only on initial hello and banned on renegotation handshakes. >>> If a client offers the "renegotiation_info" extension or the >>> TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server does not >>> reply with "renegotiation_info" in the ServerHello, then this >>> indicates that the server either does not support secure >>> renegotiation or is unwilling to use it. >> Is it allowed for a patched server to be "unwilling"? >> >> If not, drop the "or is unwilling to use it" lest it give the impression >> that such behavior is condoned. > > Above, I've suggested a couple of potential reasons why a server > (which knows about the renegotiation security hole) might simply > disable renegotiation entirely. Sure, but that's not a reason to not reply with RI when requested. It's not a reason for the server to not tell the client that it is, in fact, patched. >> Again, is it allowed for a client to be conformant to this spec and >> still not send either the extension or magic cipher suite value? > > A client may be conformant to this specification without sending > either the RI ext or the cipher suite flag, if it knows that it will > not perform or accept any requests to perform any renegotiations. The client doesn't necessarily see the renegotiation, so it can't know that it's not taking part in one. > If > it does not, the server will believe that it is an unpatched client > and expect/accept only one negotiation. If it's been patched and configured such that it talks to insecure clients. > Why indicate your willingness > to do something that you're not willing to do later anyway? > > I'd suggest adding wording to this effect, suggesting that > implementations SHOULD offer this extension only if they're willing to > accept renegotiations. Why should the client advertise that he's willing or not willing to renegotiate? What if the API and existing application code defers that decision until later? A client app that is willing renegotiate only just after submitting an HTTP request and if the user could possibly approve the client cert request. Client certs could become enabled at any time and shouldn't cause existing connections to break! IMHO a patched client should always send the magic cipher suite so the server can prevent MitM. That way you don't have to force the server into making the difficult decision as to whether or not to join in on a possibly-compromised connection. - Marsh From Nicolas.Williams@sun.com Mon Nov 30 10:50:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBC43A684C for ; Mon, 30 Nov 2009 10:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.754 X-Spam-Level: X-Spam-Status: No, score=-5.754 tagged_above=-999 required=5 tests=[AWL=0.292, 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 6dMJ3Qy74Xes for ; Mon, 30 Nov 2009 10:50:16 -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 2448428C152 for ; Mon, 30 Nov 2009 10:50:11 -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 nAUIo4sw026231 for ; Mon, 30 Nov 2009 18:50:04 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 nAUIo3FA049345 for ; Mon, 30 Nov 2009 11:50:03 -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 nAUIUp9V006844; Mon, 30 Nov 2009 12:30:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAUIUo3G006843; Mon, 30 Nov 2009 12:30:50 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Nov 2009 12:30:50 -0600 From: Nicolas Williams To: Stefan Santesson Message-ID: <20091130183050.GK773@Sun.COM> References: <20091130170745.GH773@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:50:19 -0000 On Mon, Nov 30, 2009 at 06:55:26PM +0100, Stefan Santesson wrote: > Nico, > > I think your characterization is very good. Thanks. > And I would also much rather have a fail-safe solution. > > As you say, no approach today is totally extension less, so the big > difference remaining IMO is: > > [...] Agreed. > I think we have demonstrated that the fail-safe alternative can be designed > in a secure manner. Agreed. The question is: how to reach consensus on whether to modify the RI proposal to fail safe? We're all very tired following a lengthy DDoS by the TLS WG[0]; we don't need to have a repeat on the IETF list. Sadly, I think we'll almost certainly have a repeat. Thus I'm voicing my opinion early and bailing out immediately: IMO fail-safe mechanisms are a good thing, but not something necessarily a hard requirement. I'd support a fail-safe modification to the RI proposal[1], but given that implementors are ready to deploy the RI proposal as-is, I also support the RI proposal as-is in the interest of getting a fix done sooner rather than later. [0] Jeff Hodges' very funny coinage. [1] The simplest such change would be have the peers send zeros in the extensions but modify the hellos to insert the CB data prior to hashing the hellos as part of the verify_data computation. Nico -- From marsh@extendedsubset.com Mon Nov 30 11:03:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E652E3A6951 for ; Mon, 30 Nov 2009 11:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 nvCqmbBEF9wU for ; Mon, 30 Nov 2009 11:03:01 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 147943A68FF for ; Mon, 30 Nov 2009 11:03:01 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NFBWP-0005an-KP; Mon, 30 Nov 2009 19:02:53 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8303B603C; Mon, 30 Nov 2009 19:02:52 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18elZ+odX2XSD1sJzXOnHZ7E7CG62T46sk= Message-ID: <4B1416D0.60500@extendedsubset.com> Date: Mon, 30 Nov 2009 13:02:40 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nicolas Williams , "tls@ietf.org" References: <20091130170745.GH773@Sun.COM> <20091130183050.GK773@Sun.COM> In-Reply-To: <20091130183050.GK773@Sun.COM> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:03:02 -0000 Nicolas Williams wrote: > > IMO fail-safe mechanisms are a good thing, but not something necessarily > a hard requirement. I'd support a fail-safe modification to the RI > proposal[1], but given that implementors are ready to deploy the RI > proposal as-is, I also support the RI proposal as-is in the interest of > getting a fix done sooner rather than later. Agreed. We'd all have done it differently from the beginning, but we have to ship a fix. No compromise on actual protocol security of course, but no time to delay for aesthetics either. > [1] The simplest such change would be have the peers send zeros in the > extensions but modify the hellos to insert the CB data prior to > hashing the hellos as part of the verify_data computation. Changing inputs to the hash function theoretically introduces new possibilities for attack (verify_data which looks like a valid handshake message prefix for example). I fear that any change to the way the hashing inputs are done will trigger a formal crypto review in some important deployments. We had hoped the hello extension mechanism would have been already an accepted way to extend the handshake such that it didn't violate any assumptions on which previous cryptographic analysis of the protocol had been built. - Marsh From Nicolas.Williams@sun.com Mon Nov 30 11:32:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71CC28C169 for ; Mon, 30 Nov 2009 11:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.772 X-Spam-Level: X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[AWL=0.274, 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 0hK9V77-EdO2 for ; Mon, 30 Nov 2009 11:32:33 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id EDD7628C11F for ; Mon, 30 Nov 2009 11:32:32 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAUJWBI6029784 for ; Mon, 30 Nov 2009 19:32:11 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 nAUJW8DQ013905 for ; Mon, 30 Nov 2009 12:32:08 -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 nAUJCtKA006908; Mon, 30 Nov 2009 13:12:55 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAUJCtvW006907; Mon, 30 Nov 2009 13:12:55 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Nov 2009 13:12:55 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091130191254.GN773@Sun.COM> References: <20091130170745.GH773@Sun.COM> <20091130183050.GK773@Sun.COM> <4B1416D0.60500@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1416D0.60500@extendedsubset.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:32:33 -0000 On Mon, Nov 30, 2009 at 01:02:40PM -0600, Marsh Ray wrote: > We'd all have done it differently from the beginning, but we have to > ship a fix. > > No compromise on actual protocol security of course, but no time to > delay for aesthetics either. To be clear: the fail-safe/unsafe issue is not a matter of aesthetics. > Nicolas Williams wrote: > > [1] The simplest such change would be have the peers send zeros in the > > extensions but modify the hellos to insert the CB data prior to > > hashing the hellos as part of the verify_data computation. > > Changing inputs to the hash function theoretically introduces new > possibilities for attack (verify_data which looks like a valid handshake > message prefix for example). I don't agree, but, more than anything I don't want to debate the merits of alternative designs, mine or anyone else's -- that way another DDoS lies. I should not have included that footnote; I am sorry that I did. IMO what we should do is first work on consensus as to whether to fix the fail-unsafe issue in the RI proposal as that's the main issue right now. Nico -- From Pasi.Eronen@nokia.com Mon Nov 30 11:34:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F41328C198 for ; Mon, 30 Nov 2009 11:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 PwpEnji9EQob for ; Mon, 30 Nov 2009 11:34:00 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 2C1EA3A68DF for ; Mon, 30 Nov 2009 11:33:59 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAUJXiJR002473; Mon, 30 Nov 2009 21:33:46 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 21:33:45 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 21:33:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 21:33:40 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 30 Nov 2009 20:33:39 +0100 From: To: Date: Mon, 30 Nov 2009 20:33:38 +0100 Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acpvu/KRzoJN7SYYTAmVCeljbCYqVQCN9Ybw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3118CF63@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2009 19:33:40.0608 (UTC) FILETIME=[052A0800:01CA71F4] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:34:01 -0000 Yes, you're right; my mistake (fortunately the tool for actually requesting last call makes such typos much harder, and the actual IETF Last Call message had the correct draft name). Best regards, Pasi > -----Original Message----- > From: ext Bodo Moeller [mailto:bmoeller@acm.org] > Sent: 28 November, 2009 01:47 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: tls@ietf.org > Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation >=20 > On Nov 27, 2009, at 11:26 PM, wrote: >=20 > > > > > > I have asked the secretariat to start IETF Last Call for > > draft-rescorla-tls-renegotiation-01. >=20 > No, you haven't -- or so I hope: You must have asked about draft-ietf- > tls-renegotiation-01. >=20 > Bodo >=20 From Michael.Tuexen@lurchi.franken.de Mon Nov 30 11:39:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113CE3A6833 for ; Mon, 30 Nov 2009 11:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExKFsOAtoZWk for ; Mon, 30 Nov 2009 11:39:11 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id DB3D53A68C9 for ; Mon, 30 Nov 2009 11:39:10 -0800 (PST) Received: from [IPv6:2002:508f:ce17::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:ce17:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 27AB11C0B404B; Mon, 30 Nov 2009 20:39:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <6b9359640911301031o435c8ae9w93ffffb8ac04353a@mail.gmail.com> Date: Mon, 30 Nov 2009 20:39:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> <20091130182931.39B596C3EB8@kilo.networkresonance.com> <6b9359640911301031o435c8ae9w93ffffb8ac04353a@mail.gmail.com> To: Kyle Hamilton X-Mailer: Apple Mail (2.1077) Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:39:12 -0000 On Nov 30, 2009, at 7:31 PM, Kyle Hamilton wrote: > I would support randomizing the epoch counter in DTLS, giving a 1:2^16 > chance of getting it right in a single attempt. (This follows my > observation that the hash saved from the last Finished message is > essentially the same as a named epoch.) Who chooses the epoch randomly, how does the peer know this value? Best regards Michael >=20 > -Kyle H >=20 > On Mon, Nov 30, 2009 at 10:29 AM, Eric Rescorla > wrote: >> At Mon, 30 Nov 2009 12:06:02 -0600, >> Marsh Ray wrote: >>>=20 >>> Michael T=FCxen wrote: >>>>=20 >>>> If I'm not wrong, then the attack which works against TLS does not >>>> work against DTLS, since DTLS has an epoch counter. >>>>=20 >>>> If a client tries to establish a DTLS connection and a MITM = intercepts >>>> it, establishes itself a DTLS connection, the epoch is 1. There = will be >>>> a final mismatch in the epoch and the packets will be discarded. = When >>>> using the RI extension one could enforce the sending of the alert = message. >>>> But the original attack is not possible, I think. >>>>=20 >>>> Is my analysis correct or am I overlooking something? >>>=20 >>> Can MitM do the same number of renegotitations as he does with the >>> server before splicing him? >>=20 >> Nagendray and I had this conversation last week. While I haven't done >> a complete analysis, my intuition is that DTLS is more resistant (for >> the reason you indicate) but not 100% resistant. Another concern >> would be epoch rollover: what if you do 65536 (65535?--too lazy to >> calculate) handshakes with the server and force the epoch back to 0? >>=20 >> So, probably better to use RI with DTLS as well. >>=20 >> -Ekr >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Mon Nov 30 12:18:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B3C28C18E for ; Mon, 30 Nov 2009 12:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB8f0WpO4GDV for ; Mon, 30 Nov 2009 12:18:39 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 96D9428C159 for ; Mon, 30 Nov 2009 12:18:39 -0800 (PST) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 42D1029110B for ; Mon, 30 Nov 2009 21:18:38 +0100 (CET) Received: (qmail 67087 invoked from network); 30 Nov 2009 20:18:30 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Nov 2009 20:18:30 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 30 Nov 2009 21:18:26 +0100 From: Stefan Santesson To: Nicolas Williams , Marsh Ray Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acpx+kXIhSf2nnF5IE+G0AbiZ7lKMw== In-Reply-To: <20091130191254.GN773@Sun.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:18:40 -0000 Nico, On 09-11-30 8:12 PM, "Nicolas Williams" wrote: > >> Nicolas Williams wrote: >>> [1] The simplest such change would be have the peers send zeros in the >>> extensions but modify the hellos to insert the CB data prior to >>> hashing the hellos as part of the verify_data computation. >> >> Changing inputs to the hash function theoretically introduces new >> possibilities for attack (verify_data which looks like a valid handshake >> message prefix for example). > > I don't agree, but, more than anything I don't want to debate the merits > of alternative designs, mine or anyone else's -- that way another DDoS > lies. I should not have included that footnote; I am sorry that I did. I don't want to start a new discussion about this either, but for the record I agree with you. The attack described by David-Sarah (injecting messages to make a the client primary handshake appear as renegotiation) does not work on the approach you describe. We can just conclude that there are many ways through which once could design a fail-safe approach. The question is whether it is worth the effort. I believe that it is worth it if we can agree on one shortly (during the ietf last call). If we can't then we'd better get the fix out rather than dragging this on forever. /Stefan From dispensa@phonefactor.com Mon Nov 30 12:30:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191AA3A69C7 for ; Mon, 30 Nov 2009 12:30:13 -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 Qv19i-RI0gOA for ; Mon, 30 Nov 2009 12:30:12 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 1A5C53A69BE for ; Mon, 30 Nov 2009 12:30:11 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKSxQrTGZm7XvLZPKbavYX83QLjxy8kvnF@postini.com; Mon, 30 Nov 2009 12:30:05 PST Received: from 10.10.10.89 ([10.10.10.89]) by pos-exch1.corp.positivenetworks.net ([204.13.120.8]) with Microsoft Exchange Server HTTP-DAV ; Mon, 30 Nov 2009 20:27:56 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 30 Nov 2009 14:30:03 -0600 From: Steve Dispensa To: "tls@ietf.org" Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acpx++U6jcwbZVep2EW/ZhEe1cBmcQ== In-Reply-To: <4B13F65B.40204@extendedsubset.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:30:13 -0000 On 11/30/09 10:44 AM, "Marsh Ray" wrote: > Stefan Santesson wrote: >> >> This is my count: >> >> Support an alternative solution: 6 people >> Open for an alternative solution: 3 people >> Neutral: 4 People >> Support the current tls draft: 7 people >> Conditional support for the current draft: 2 people > > Please put me down in support of draft-ietf-tls-renegotiation-01 I also support draft-ietf-tls-renegotiation-01. -Steve From Pasi.Eronen@nokia.com Mon Nov 30 12:39:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA13D3A6988 for ; Mon, 30 Nov 2009 12:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 4JachDmpZ4Dz for ; Mon, 30 Nov 2009 12:39:52 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6DF943A67D9 for ; Mon, 30 Nov 2009 12:39:51 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAUKdWPI021851; Mon, 30 Nov 2009 22:39:39 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 22:38:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 22:38:09 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 30 Nov 2009 21:38:04 +0100 From: To: , Date: Mon, 30 Nov 2009 21:38:02 +0100 Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: AcpvsK00o1AiVoleTQuKgrA4F9s+kwCE+L5jAAyQt4A= Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2009 20:38:09.0573 (UTC) FILETIME=[073F3D50:01CA71FD] X-Nokia-AV: Clean Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:39:53 -0000 Stefan Santesson wrote: > > I've gone through the list archives for the past month, and it > > seems a large majority of the WG members support the overall > > approach in this draft (with a small, but very vocal, minority > > preferring a totally extension-less approach to signalling). >=20 > I made a count through all people that has raised their voice on > this list and included all e-mail that was sent the past week. I > don't think it is fair to include any statements older than that. >=20 > This is my count: >=20 > Support an alternative solution: 6 people > Open for an alternative solution: 3 people > Neutral: 4 People > Support the current tls draft: 7 people > Conditional support for the current draft: 2 people >=20 > Looks fairly even to me. I think this depends very much on what you mean by the "alternative solution" -- it seems you're not referring to, for example, draft-mrex-tls-secure-renegotiation-01. In my quoted text above, the "large majority" referred mostly to people who've said using TLS extensions (in one way or another) is OK, and the "small minority" was objecting to proposals involving TLS extensions in any way. (In this question, I do not think ignoring opinions expressed more than 7 days ago is a reasonable way to judge the situation.) However, in your later email (on Monday) you seemed to say that we have settled this issue already: > As you say, no approach today is totally extension less, so the big > difference remaining IMO is: > > 1) The fail-unsafe approach based on sending verify_data in extensions. > > 2) The Fail-safe approach based on injecting varify_data into the > handshake hash calculation, but not sending them over the > wire. (This approach uses extensions for signaling but with absent > data) > > Everything else is more or less the same. This surprised me a bit (but possibly the surprise is a positive one). I would be interested in hearing from folks who've earlier opposed the use of extensions whether this reflects their current views, too. If it does, I think we've made a lot of progress, and can still tweak the final difference (whether to send verify_data over-the-wire or not)=20 based on discussion during the IETF last call. I do not claim that a large majority currently strongly prefers sending the old verify_data over-the-wire in the extension data. Much smaller number of people (compared to the signalling issue) have expressed any opinions about this, and also, I would expect that a smaller number of people care very strongly either way. And BTW, in this question I agree that counting opinions expressed much more than a week ago probably isn't that good. So if someone (any reader of this message) cares very strongly either way,=20 I would suggest saying so on the list (if you haven't done so already recently). Best regards,=20 Pasi From stefan@aaa-sec.com Mon Nov 30 12:46:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7933A69BE for ; Mon, 30 Nov 2009 12:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juwx5PiBOhnu for ; Mon, 30 Nov 2009 12:46:34 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 6A8703A699C for ; Mon, 30 Nov 2009 12:46:34 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8741628C30E for ; Mon, 30 Nov 2009 21:46:34 +0100 (CET) Received: (qmail 53457 invoked from network); 30 Nov 2009 20:46:26 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Nov 2009 20:46:26 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 30 Nov 2009 21:46:24 +0100 From: Stefan Santesson To: Steve Dispensa , "tls@ietf.org" Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acpx++U6jcwbZVep2EW/ZhEe1cBmcQAAki5P In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:46:35 -0000 Please.... I'm not keeping score :) I did a one off count coming up with this estimate to get a feeling for where we are. I do not intend to update this score and It was not an attempt to do a rouge straw-poll. It is up to the IESG and WG chairs to ask for and determine consensus. /Stefan On 09-11-30 9:30 PM, "Steve Dispensa" wrote: > On 11/30/09 10:44 AM, "Marsh Ray" wrote: > >> Stefan Santesson wrote: >>> >>> This is my count: >>> >>> Support an alternative solution: 6 people >>> Open for an alternative solution: 3 people >>> Neutral: 4 People >>> Support the current tls draft: 7 people >>> Conditional support for the current draft: 2 people >> >> Please put me down in support of draft-ietf-tls-renegotiation-01 > > I also support draft-ietf-tls-renegotiation-01. > > -Steve > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jwkckid1@ix.netcom.com Mon Nov 30 12:47:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51EF728C159 for ; Mon, 30 Nov 2009 12:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 W+ralXfaQTR0 for ; Mon, 30 Nov 2009 12:47:06 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id A4BB928C131 for ; Mon, 30 Nov 2009 12:47:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=GVQXW3uubWOjntU8hK2Kpjyr1XSt4U0pigh7LO+uvwTx8vBkJZldGGbwWaoCySEs; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NFD91-0003sC-UN; Mon, 30 Nov 2009 15:46:51 -0500 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 30 Nov 2009 15:46:51 -0500 Message-ID: <32069276.1259614011916.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Mon, 30 Nov 2009 14:46:51 -0600 (GMT-06:00) From: "Jeffrey A. Williams" To: Todd Glassey , Erick O Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688f4deaa983d54f87b6299e73418557f55350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Cc: ietf-honest@lists.iadl.org, tls@ietf.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:47:10 -0000 Todd and all, All good points here! Well done! >:) -----Original Message----- >From: Todd Glassey >Sent: Sep 18, 2009 9:23 AM >To: Erick O >Cc: Dean Anderson , ietf-honest@lists.iadl.org, martin.rex@sap.com, tls@ietf.org >Subject: Re: [Ietf-honest] [TLS] Last Call: draft-ietf-tls-extractor (Keying > >Erick O wrote: >> >> >> ------------------------------------------------------------------------ >> *From:* Martin Rex >> *To:* Dean Anderson >> *Cc:* tglassey@earthlink.net; ietf-honest@lists.iadl.org; tls@ietf.org >> *Sent:* Thursday, July 23, 2009 2:34:16 PM >> *Subject:* Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor >> (Keying >> >> Dean Anderson wrote: >> >> > >> > This is a problem. The official statement is the IPR disclosure, which >> > should contain the terms used by the IETF in its decision to approve the >> > document. >Dan - the IPR notice is a statement of the ownership of the IP and >NOTHING MORE. It is NOT a contractual grant of anything. It is not >authenticated and the process doesnt meet any legal requirements in the >real world for transferring commercial rights to anyone for anything. >> Certicom should not be able to alter the terms after the fact, >> > which it seems to have just admitted doing. >Wrong - Certichron can alter anything it wants after informing the IETF >of its (Certichron's) ownership of those technologies. > >The IETF's decision to allow a standard or not based on whether the IETF >is given ownership of the IP implementing that standard in the real >world in the standard is a form of blackmail and needs to be formally >prosecuted as tortuous interference and antitrust IMHO. >> >> The IETF is NOT asking for an irrevocable "Grant" in an IPR disclosure. >> >> The problem here is that submitting an URL for the real IPR disclosure >> in the IETF disclosure form is subverting to idea that the IETF >> can archive the IPR disclosures in their original form. >Yes but that's the flaw in the IETF's system. >> >> >> > >> > I think that we have to consider rejecting documents where the terms are >> > not definite and/or can be altered at the whim of the patent holder. >> >> Copyright terms stick to the published text or code when they're >> published (under the condition they're rightfully issued). >> >> >> AFAIK, License grants for patents are rarely issued as "irrevocable", >> which means that the terms can be cancelled/terminated. >Yep... >> >> >> -Martin >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.104/2379 - Release Date: 09/17/09 15:55:00 >> >> > >_______________________________________________ >Ietf-honest mailing list >Ietf-honest@lists.iadl.org >http://lists.iadl.org/mailman/listinfo/ietf-honest Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 294k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From stefan@aaa-sec.com Mon Nov 30 12:57:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ACF3A689E for ; Mon, 30 Nov 2009 12:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGGqLsJBYLam for ; Mon, 30 Nov 2009 12:57:34 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id BFE3228C137 for ; Mon, 30 Nov 2009 12:57:33 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D1BF628CF6C for ; Mon, 30 Nov 2009 21:56:52 +0100 (CET) Received: (qmail 77639 invoked from network); 30 Nov 2009 20:56:44 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Nov 2009 20:56:44 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 30 Nov 2009 21:56:43 +0100 From: Stefan Santesson To: , Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: AcpvsK00o1AiVoleTQuKgrA4F9s+kwCE+L5jAAyQt4AAAjL3iQ== In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:57:35 -0000 Pasi, Thanks for a good and clarifying mail. Yes, all proposals are currently using extensions for the server to client signaling and all proposals are currently using the magic CipherSuite only for client to server signaling on initial handshakes. This will also be reflected in the new alternative draft to be posted, hopefully within 24 hours from now. In this sense the two approaches are a lot closer now. The major difference now is that one proposal includes the data in the extensions and is fail-unsafe, while the alternative feeds that data directly into the handshake hash calculation and is fail-safe. There are minor differences also in the signaling on renegotiations, but I regard that as minor. /Stefan On 09-11-30 9:38 PM, "Pasi.Eronen@nokia.com" wrote: > > > Stefan Santesson wrote: > >>> I've gone through the list archives for the past month, and it >>> seems a large majority of the WG members support the overall >>> approach in this draft (with a small, but very vocal, minority >>> preferring a totally extension-less approach to signalling). >> >> I made a count through all people that has raised their voice on >> this list and included all e-mail that was sent the past week. I >> don't think it is fair to include any statements older than that. >> >> This is my count: >> >> Support an alternative solution: 6 people >> Open for an alternative solution: 3 people >> Neutral: 4 People >> Support the current tls draft: 7 people >> Conditional support for the current draft: 2 people >> >> Looks fairly even to me. > > I think this depends very much on what you mean by the "alternative > solution" -- it seems you're not referring to, for example, > draft-mrex-tls-secure-renegotiation-01. > > In my quoted text above, the "large majority" referred mostly to > people who've said using TLS extensions (in one way or another) is OK, > and the "small minority" was objecting to proposals involving TLS > extensions in any way. (In this question, I do not think ignoring > opinions expressed more than 7 days ago is a reasonable way to judge > the situation.) > > However, in your later email (on Monday) you seemed to say that we > have settled this issue already: > >> As you say, no approach today is totally extension less, so the big >> difference remaining IMO is: >> >> 1) The fail-unsafe approach based on sending verify_data in extensions. >> >> 2) The Fail-safe approach based on injecting varify_data into the >> handshake hash calculation, but not sending them over the >> wire. (This approach uses extensions for signaling but with absent >> data) >> >> Everything else is more or less the same. > > This surprised me a bit (but possibly the surprise is a positive one). > I would be interested in hearing from folks who've earlier opposed the > use of extensions whether this reflects their current views, too. > > If it does, I think we've made a lot of progress, and can still tweak > the final difference (whether to send verify_data over-the-wire or not) > based on discussion during the IETF last call. > > I do not claim that a large majority currently strongly prefers > sending the old verify_data over-the-wire in the extension data. Much > smaller number of people (compared to the signalling issue) have > expressed any opinions about this, and also, I would expect that a > smaller number of people care very strongly either way. > > And BTW, in this question I agree that counting opinions expressed > much more than a week ago probably isn't that good. So if someone > (any reader of this message) cares very strongly either way, > I would suggest saying so on the list (if you haven't done so > already recently). > > Best regards, > Pasi From ekr@networkresonance.com Mon Nov 30 13:05:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DAF03A689A for ; Mon, 30 Nov 2009 13:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.061 X-Spam-Level: X-Spam-Status: No, score=0.061 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcYN0n35UbFz for ; Mon, 30 Nov 2009 13:04:59 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 379133A6894 for ; Mon, 30 Nov 2009 13:04:59 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D8EA76C3EE1; Mon, 30 Nov 2009 13:05:55 -0800 (PST) Date: Mon, 30 Nov 2009 13:05:54 -0800 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20091130170745.GH773@Sun.COM> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <20091130170745.GH773@Sun.COM> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091130210555.D8EA76C3EE1@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:05:00 -0000 At Mon, 30 Nov 2009 11:07:45 -0600, Nicolas Williams wrote: > > On Fri, Nov 27, 2009 at 11:26:34PM +0100, Pasi.Eronen@nokia.com wrote: > > > > > > I have asked the secretariat to start IETF Last Call for > > draft-rescorla-tls-renegotiation-01. > > > > I've gone through the list archives for the past month, and it seems a > > large majority of the WG members support the overall approach in this > > draft (with a small, but very vocal, minority preferring a totally > > extension-less approach to signalling). > > I don't think that's a fair nor complete characterization of the current > differences of opinion. A more complete and correct characterization > might be: > > - The RI proposal has a fail-unsafe requirement that peers check the > contents of the extensions sent. > > NOTE: A fix for this wouldn't require an extension-less signalling > solution. > > [IMO: This is serious objection that goes beyond protocol design > aesthetics or ease of retrofitting for SSLv3. I think we can > live without a fix for this problem, but I'd much rather have a > fail-safe solution.] I don't really agree that this is a serious objection. As I said earlier, the security of TLS requires that the peer behave correctly in a variety of unobservable ways. If it doesn't, we have far more serious security problems than this (in particular, in order for the failure you're concerned about to occur, this failure requires *both* sides to be incorrectly implemented, whereas there are plenty of issues that can be created by merely one side being incorrect). Moreover, there *are* implementation errors where the various proposed alternative signalling mechanisms can go wrong as well, as our discussion over the past few days indicates. So I can't even agree with the characterization of this issue as "fail-safe" versus "fail-unsafe". Rather, each solution is subject to different kinds of implementation screwups. I don't find the argument that the screwups you can make with RI are somehow easier to be particularly convincing. Moreover, if you're really concerned about TLS being safe in the face of implementation errors, you should worry about designing mechanisms that are safe in the face of PRNG failure, seeing as we've seen at least two such errors in live TLS stacks. -Ekr From SRS0=PRUA=HS=acm.org=bmoeller@srs.kundenserver.de Mon Nov 30 13:10:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12053A69D5; Mon, 30 Nov 2009 13:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 cob3EMDDlFqi; Mon, 30 Nov 2009 13:10:14 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id A3CE93A69D3; Mon, 30 Nov 2009 13:10:13 -0800 (PST) Received: from bmoeller-macbookpro.fritz.box (77-57-209-74.dclient.hispeed.ch [77.57.209.74]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MQM9c-1Ngknn0mya-00UIvP; Mon, 30 Nov 2009 22:10:03 +0100 From: Bodo Moeller To: ietf@ietf.org In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Nov 2009 22:10:02 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+1TCuAPeejR7YT2j0Dv5I9JUG0FJ0cNya1xX/ yZlhROCVMP6sB/vsqS1jxblpxv/15x5WgEXLQ2yhFSun9xS0y7 eMgaeB9rlJzKrPtbLKOCQ== Cc: "tls@ietf.org Working Group" Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:13:41 -0000 On Nov 30, 2009, at 4:37 PM, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > > - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-12-14. I support the move, contingent to two clean-ups to specified behavior: 1. Section 3 specifies "For ClientHellos which are renegotiating, this field contains the verify_data from the Finished message sent by the client on the immediately previous handshake", and "For ServerHellos which are renegotiating, this field contains the concatenation of the verify_data values sent by the client and the server (in that order) on the immediately previous handshake." There is no good reason for this asymmetry of having just the client's verify_data in the client's message, but both the client's and the server's verify_data in the server's message -- the latter is pure overhead, both in the specification and in the on-the-wire protocol. To remove the overhead from both, the second sentence should be saying, "For ServerHellos which are renegotiating, this field contains the verify_data sent by the server on the immediately previous handshake" (according changes to dependent parts of the specification then should be made). For earlier Internet Drafts in the series preceding draft-ietf-tls- renegotiation-01.txt (draft-rescorla-tls-renegotiation.00.txt, etc.), a reason to keep the current text would have been to maintain compatibility with early implementations of those Internet Drafts. However, draft-ietf-tls-renegotiation-01 has a newer TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks compatibility with those early implementations anyway. (This means that now, changing the ServerHello extension definition as suggested above gives the beneficial side-effect of exposing premature implementations, besides merely avoiding overhead. Those incomplete implementations will be more obviously incompatible because they'd still be using the protocol variant with overhead, instead of just differing subtly in the behavior if faced with TLS_RENEGO_PROTECTION_REQUEST.) 2. The Security Considerations section of draft-ietf-tls- renegotiation-01.txt (section 7) includes language that unnecessarily restricts the flexibility that the TLS protocol specifically provides for, regulating areas that the TLS standard intentionally does not specify (RFC 5246 section 1) -- the current Internet Draft says: "By default, TLS implementations conforming to this document MUST verify that once the peer has been identified and authenticated within the TLS handshake, the identity does not change on subsequent renegotiations. For certificate based cipher suites, this means bitwise equality of the end-entity certificate. If the other end attempts to authenticate with a different identity, the renegotiation MUST fail. If the server_name extension is used, it MUST NOT change when doing renegotiation." There is no security reason for this restriction. This sounds like a bad and incomplete workaround for certain problems with TLS that the updated protocol does not need a workaround for at all, because the protocol update is all about properly *solving* those problems. Keeping this language in the specification would have the weird implication that applications that *need* the flexibility provided by the TLS protocol (e.g., to allow renegotiation handshakes to switch to a different ciphersuite, which may require a different certificate) would have to to *skip* implementing the protocol update, and thus stay vulnerable. The new restriction that draft-ietf-tls-renegotiation-01.txt tries to sneak in thus seems harmful both for interoperability and for security. I haven't seen any signs of working group consensus on including this new restriction. Bodo From stefan@aaa-sec.com Mon Nov 30 13:14:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991623A69DD for ; Mon, 30 Nov 2009 13:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okMGuXnnwVEF for ; Mon, 30 Nov 2009 13:14:13 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id A8AD23A69BA for ; Mon, 30 Nov 2009 13:14:13 -0800 (PST) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A3A39291B98 for ; Mon, 30 Nov 2009 22:13:35 +0100 (CET) Received: (qmail 26289 invoked from network); 30 Nov 2009 21:13:27 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Nov 2009 21:13:27 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 30 Nov 2009 22:13:25 +0100 From: Stefan Santesson To: , Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: AcpvsK00o1AiVoleTQuKgrA4F9s+kwCE+L5jAAyQt4AAAshGZw== In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:14:15 -0000 Pasi, On 09-11-30 9:38 PM, "Pasi.Eronen@nokia.com" wrote: > > This surprised me a bit (but possibly the surprise is a positive one). > I would be interested in hearing from folks who've earlier opposed the > use of extensions whether this reflects their current views, too. Some sources of relevance concerning this issue: http://www.ietf.org/mail-archive/web/tls/current/msg04742.html ,and http://www.ietf.org/mail-archive/web/tls/current/msg04789.html From marsh@extendedsubset.com Mon Nov 30 13:53:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63DB3A6931; Mon, 30 Nov 2009 13:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 WbMZZXs81tAN; Mon, 30 Nov 2009 13:53:06 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id C94E83A692C; Mon, 30 Nov 2009 13:53:06 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1NFEB1-0000C9-Ch; Mon, 30 Nov 2009 21:52:59 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 00EDF603C; Mon, 30 Nov 2009 21:52:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+1LfXoQxr962VkM3yyCcnDcGlqoK7gAk8= Message-ID: <4B143EAC.9050301@extendedsubset.com> Date: Mon, 30 Nov 2009 15:52:44 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bodo Moeller References: <20091130153734.D44C63A6AA9@core3.amsl.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, "tls@ietf.org Working Group" Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:53:07 -0000 Bodo Moeller wrote: > > There is no good reason for this asymmetry of having just the client's > verify_data in the client's message, but both the client's and the > server's verify_data in the server's message -- the latter is pure > overhead, both in the specification and in the on-the-wire protocol. To > remove the overhead from both, the second sentence should be saying, > "For ServerHellos which are renegotiating, this field contains the > verify_data sent by the server on the immediately previous handshake" > (according changes to dependent parts of the specification then should > be made). Good point. > For earlier Internet Drafts in the series preceding > draft-ietf-tls-renegotiation-01.txt > (draft-rescorla-tls-renegotiation.00.txt, etc.), a reason to keep the > current text would have been to maintain compatibility with early > implementations of those Internet Drafts. However, > draft-ietf-tls-renegotiation-01 has a newer > TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks compatibility > with those early implementations anyway. > > (This means that now, changing the ServerHello extension definition as > suggested above gives the beneficial side-effect of exposing premature > implementations, besides merely avoiding overhead. Those incomplete > implementations will be more obviously incompatible because they'd still > be using the protocol variant with overhead, instead of just differing > subtly in the behavior if faced with TLS_RENEGO_PROTECTION_REQUEST.) I don't think any of those implementations have shipped, and I don't think anyone has advertised that code as anything but experimental. It might not hurt for the IANA to assign a different number to the extension than what was used for testing. > 2. The Security Considerations section of > draft-ietf-tls-renegotiation-01.txt (section 7) includes language that > unnecessarily restricts the flexibility that the TLS protocol > specifically provides for, regulating areas that the TLS standard > intentionally does not specify (RFC 5246 section 1) -- the current > Internet Draft says: > > "By default, TLS implementations conforming to this document MUST verify > that once the peer has been identified and authenticated within the TLS > handshake, the identity does not change on subsequent renegotiations. > For certificate based cipher suites, this means bitwise equality of the > end-entity certificate. If the other end attempts to authenticate with a > different identity, the renegotiation MUST fail. If the server_name > extension is used, it MUST NOT change when doing renegotiation." > > There is no security reason for this restriction. +1 Agree > This sounds like a > bad and incomplete workaround for certain problems with TLS that the > updated protocol does not need a workaround for at all, because the > protocol update is all about properly *solving* those problems. > > Keeping this language in the specification would have the weird > implication that applications that *need* the flexibility provided by > the TLS protocol (e.g., to allow renegotiation handshakes to switch to a > different ciphersuite, which may require a different certificate) would > have to to *skip* implementing the protocol update, and thus stay > vulnerable. Excellent point. Although the sentence after the one you quoted seems to say that implementations are allowed to do it anyway if they choose. Which raises the question as to what this language actually means for the wire protocol, anyway. > The new restriction that draft-ietf-tls-renegotiation-01.txt tries to > sneak in thus seems harmful both for interoperability and for security. > I haven't seen any signs of working group consensus on including this > new restriction. Details about which certificates endpoints should be allowed or forbidden to negotiate is outside the scope of this bugfix. We should remove it. - Marsh From noskov@microsoft.com Mon Nov 30 14:00:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2863A6931; Mon, 30 Nov 2009 14:00:27 -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 hR8SAPT6zCVh; Mon, 30 Nov 2009 14:00:26 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D75773A68FD; Mon, 30 Nov 2009 14:00:26 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Nov 2009 14:00:45 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.0.639.20; Mon, 30 Nov 2009 14:00:08 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 30 Nov 2009 14:00:08 -0800 From: Nasko Oskov To: Bodo Moeller , "ietf@ietf.org" Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: AQHKcdN+XBvSZCgznUqCdcmUbDKLNpFPpWsA//+HBYA= Date: Mon, 30 Nov 2009 21:58:05 +0000 Deferred-Delivery: Mon, 30 Nov 2009 21:59:00 +0000 Message-ID: References: <20091130153734.D44C63A6AA9@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org Working Group" Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 22:00:27 -0000 Bodo Moeller wrote: >On Nov 30, 2009, at 4:37 PM, The IESG wrote: > >> The IESG has received a request from the Transport Layer Security WG >> (tls) to consider the following document: >> >> - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits=20 >> final comments on this action. Please send substantive comments to=20 >> the ietf@ietf.org mailing lists by 2009-12-14. > >I support the move, contingent to two clean-ups to specified behavior: I support the 01 version of the draft, assuming we address this point: >2. The Security Considerations section of draft-ietf-tls- >renegotiation-01.txt (section 7) includes language that unnecessarily >restricts the flexibility that the TLS protocol specifically provides for, >regulating areas that the TLS standard intentionally does not specify (RFC >5246 section 1) -- the current Internet Draft says: > >"By default, TLS implementations conforming to this document MUST verify >that once the peer has been identified and authenticated within the TLS >handshake, the identity does not change on subsequent renegotiations. For >certificate based cipher suites, this means bitwise equality of the >end-entity certificate. If the other end attempts to authenticate with a >different identity, the renegotiation MUST fail. If the server_name >extension is used, it MUST NOT change when doing renegotiation." > >There is no security reason for this restriction. This sounds like a bad >and incomplete workaround for certain problems with TLS that the updated >protocol does not need a workaround for at all, because the protocol updat= e >is all about properly *solving* those problems. I agree that this restriction is not necessary for solving the current problem. If the section should stay, I would vote for making it a SHOULD an= d definitely not a MUST. >Keeping this language in the specification would have the weird implicatio= n >that applications that *need* the flexibility provided by the TLS protocol >(e.g., to allow renegotiation handshakes to switch to a different >ciphersuite, which may require a different certificate) would have to to >*skip* implementing the protocol update, and thus stay vulnerable. What about certificate renewal? Once a cert is renewed, it is different whe= n it comes to bitwise comparison, yet it is the same identity. I do not think doing bitwise comparisons and dealing with identity at the TLS layer should be part of this draft. Nasko From stefan@aaa-sec.com Mon Nov 30 15:06:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E435528C140 for ; Mon, 30 Nov 2009 15:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc-kzdjOTBke for ; Mon, 30 Nov 2009 15:06:59 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id AE65328C15A for ; Mon, 30 Nov 2009 15:06:58 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 841EF28ACB6 for ; Tue, 1 Dec 2009 00:06:58 +0100 (CET) Received: (qmail 49276 invoked from network); 30 Nov 2009 23:06:49 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Nov 2009 23:06:49 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 01 Dec 2009 00:06:48 +0100 From: Stefan Santesson To: Eric Rescorla , Nicolas Williams Message-ID: Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: AcpyEcsLvLlGjxxy6UCFAJU5upo4XA== In-Reply-To: <20091130210555.D8EA76C3EE1@kilo.networkresonance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:07:00 -0000 Eric, On 09-11-30 10:05 PM, "Eric Rescorla" wrote: >> [IMO: This is serious objection that goes beyond protocol design >> aesthetics or ease of retrofitting for SSLv3. I think we can >> live without a fix for this problem, but I'd much rather have a >> fail-safe solution.] > > I don't really agree that this is a serious objection. As I said > earlier, the security of TLS requires that the peer behave correctly > in a variety of unobservable ways. If it doesn't, we have far > more serious security problems than this (in particular, in order > for the failure you're concerned about to occur, this failure > requires *both* sides to be incorrectly implemented, whereas there > are plenty of issues that can be created by merely one side being > incorrect). > Yes, the current draft is doing a good job at keeping possible one sided failures to the minimum. I think the most severe one side failure would be if a client, signaling initial handshake, would somehow trick the server to reply with an empty RI extension, even though it is doing a renegotiation. > Moreover, there *are* implementation errors where the various proposed > alternative signalling mechanisms can go wrong as well, as our discussion > over the past few days indicates. I think those were all resolved though. > So I can't even agree with the > characterization of this issue as "fail-safe" versus "fail-unsafe". > Rather, each solution is subject to different kinds of implementation > screwups. I don't find the argument that the screwups you can > make with RI are somehow easier to be particularly convincing. > I have re-evaluated my position. I still think the characterization is correct, but agree that the risk for failing following the current draft is not significant. However, I remains my belief that the implicit approach has better security properties by design. > Moreover, if you're really concerned about TLS being safe in the face > of implementation errors, you should worry about designing mechanisms > that are safe in the face of PRNG failure, seeing as we've seen at > least two such errors in live TLS stacks. The fact that there are many ways to do implementation errors, is not a reason to not select the best possible design. I find it much more convincing if the general opinion is that the "implicit" design requires too intrusive changes to the core TLS design, alternatively is to hard to implement. But if it is easier to implement in legacy implementations (e.g. by not requiring clients or servers to extract and insert data in TLS extensions), then it might actually be worth it. /Stefan From djhopwood@googlemail.com Mon Nov 30 15:20:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6B83A69E8; Mon, 30 Nov 2009 15:20:04 -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 GTL9EPbikkSR; Mon, 30 Nov 2009 15:20:03 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id DDEA83A6847; Mon, 30 Nov 2009 15:20:02 -0800 (PST) Received: by ewy6 with SMTP id 6so3505131ewy.29 for ; Mon, 30 Nov 2009 15:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=rOd8nxuPof0h/WS2xiYOBJ3bIDL0CU5KAEmG18pAK0w=; b=qvtrXGdXYfEoWlMlWtgVYNTowR1fJMGtIRCRg4/k5u2zHceGQykLlTaLeGkbUAinhU SNxREWr9bWib3D86ihBrHUGh8N5+ETY84yyxUF2d5q8HbF2gchgZ3EFg1cm7VBOaFM+w te5VbhLoOhpwGQxlAaY2jHVXm2NoPfPNVEj70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=Z42ePs6YdLVzTrGgwJHfjd2F/OkMGC0gLEqFkMS2DKLNxO5HP+EZRg8UdPO2Kb3xoB y6pOt99OqPtVBHj9TvOLDadNjL36POMQJJaGhlfWjvI7T+ZZzmvOMq9O6+4EVg09Aj6O AiICaSDjjDWYGs90lxd2uusLJSI8lJ00BMlXE= Received: by 10.213.25.69 with SMTP id y5mr277855ebb.54.1259623189994; Mon, 30 Nov 2009 15:19:49 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 14sm2819662ewy.7.2009.11.30.15.19.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 15:19:49 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B14530C.5040403@jacaranda.org> Date: Mon, 30 Nov 2009 23:19:40 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: ietf@ietf.org References: <20091130153734.D44C63A6AA9@core3.amsl.com> In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3C525D098C9F03AF11E9DA47" Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:20:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C525D098C9F03AF11E9DA47 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The IESG wrote: > The IESG has received a request from the Transport Layer Security WG=20 > (tls) to consider the following document: >=20 > - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the= > ietf@ietf.org mailing lists by 2009-12-14. Exceptionally,=20 > comments may be sent to iesg@ietf.org instead. In either case, please=20 > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt= I believe the decision to take this draft to Last Call was premature, and= that further discussion in the WG is necessary before deciding whether to= adopt draft-ietf-tls-renegotiation or an alternative. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig3C525D098C9F03AF11E9DA47 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksUUxMACgkQWUc8YzyzqAcq4wD9GFR/6wbn6P3rXSSlCIM94/Dh P1UUfENSvTLAcgRpg2IA+waXxOlm/Bo+VJbuwWULgpqPIa3z38MCzesN0HB5ZfLk =u06A -----END PGP SIGNATURE----- --------------enig3C525D098C9F03AF11E9DA47-- From djhopwood@googlemail.com Mon Nov 30 15:24:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8CD3A697D for ; Mon, 30 Nov 2009 15:24:06 -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 zuDzbyTrVvyF for ; Mon, 30 Nov 2009 15:24:05 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id BA5243A68D8 for ; Mon, 30 Nov 2009 15:24:04 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so1010695eyf.51 for ; Mon, 30 Nov 2009 15:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=7LkyzL436F3sb/7vEafIJHn67WDskn7Tx7AH1qYZazQ=; b=NUaefapGrNUyohWBJu8w7kRRxtcv0vtJY4I1kPof7rf6w+nB3iq/6NrlmyrZ91rzCD wRXda44L+VHsGSthmrUcdoVOD5AOR3CuMJSD3ApE7ADpiegmXvSys56j+RiGHEVCzoCs aYvkU3goxFkxBLvMwBUfGjxxGa7GX1gp+FbOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=wwvWuu6CiqgGcGv55LfWP1QjGjCV96rlqZEKuCJP9hveElVFDRt0nPeLow7eJs30Mg FsUKF+Rczp/d60lBQSgcIdeWzWH+Zk7TDwWYrUJPMdx5QUyGTzmrzudZGufxSgtT9pZi v2KUWgqbnPIWrnjZjlFIP+VMNIArZaHhlzDEg= Received: by 10.213.51.3 with SMTP id b3mr5541065ebg.31.1259623433505; Mon, 30 Nov 2009 15:23:53 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 13sm2822738ewy.13.2009.11.30.15.23.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 15:23:52 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B145406.7050905@jacaranda.org> Date: Mon, 30 Nov 2009 23:23:50 +0000 From: David-Sarah Hopwood User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tls@ietf.org References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <20091130170745.GH773@Sun.COM> In-Reply-To: <20091130170745.GH773@Sun.COM> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3406346B6F96FDE8B3DA402B" Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:24:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3406346B6F96FDE8B3DA402B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > On Fri, Nov 27, 2009 at 11:26:34PM +0100, Pasi.Eronen@nokia.com wrote: >> >> >> I have asked the secretariat to start IETF Last Call for >> draft-rescorla-tls-renegotiation-01. >> >> I've gone through the list archives for the past month, and it seems a= >> large majority of the WG members support the overall approach in this >> draft (with a small, but very vocal, minority preferring a totally >> extension-less approach to signalling). >=20 > I don't think that's a fair nor complete characterization of the curren= t > differences of opinion. A more complete and correct characterization > might be: >=20 > - The RI proposal has a fail-unsafe requirement that peers check the > contents of the extensions sent. >=20 > NOTE: A fix for this wouldn't require an extension-less signalling > solution. >=20 > [IMO: This is serious objection that goes beyond protocol design > aesthetics or ease of retrofitting for SSLv3. I think we can > live without a fix for this problem, but I'd much rather have a > fail-safe solution.] >=20 > - There seems to be a desire, among some, for a signalling solution > that is somehow easier to retrofit for SSLv3 implementations. This > couldn't be an extension-less scheme, since some bits are needed to > signal the use of the fix in the client's initial hello, but it migh= t > avoid the use of server hello extensions. >=20 > [IMO: This is a concern that we can safely ignore.] I agree completely with both your characterization of the situation, and statements of opinion. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig3406346B6F96FDE8B3DA402B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAksUVAcACgkQWUc8YzyzqAf6kwD+NftZIvFC0P1zpHihBcyA+aNk RWPZDWm2RVzdR0UbNUMA/icHWUajg+3YLOejhoxkr4kI/xSZ3BPipcejYBzPSJIQ =9f6M -----END PGP SIGNATURE----- --------------enig3406346B6F96FDE8B3DA402B-- From Nicolas.Williams@sun.com Mon Nov 30 15:42:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B543A67B3 for ; Mon, 30 Nov 2009 15:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.339, 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 8g8cb7R4BbPL for ; Mon, 30 Nov 2009 15:42:40 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3A7BF28C143 for ; Mon, 30 Nov 2009 15:42:40 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAUNgWlt019607 for ; Mon, 30 Nov 2009 23:42:32 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 nAUNgW6d055378 for ; Mon, 30 Nov 2009 16:42:32 -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 nAUNUkek007109; Mon, 30 Nov 2009 17:30:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAUNUjBM007108; Mon, 30 Nov 2009 17:30:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 30 Nov 2009 17:30:45 -0600 From: Nicolas Williams To: David-Sarah Hopwood Message-ID: <20091130233045.GA773@Sun.COM> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <20091130170745.GH773@Sun.COM> <4B145406.7050905@jacaranda.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B145406.7050905@jacaranda.org> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:42:41 -0000 On Mon, Nov 30, 2009 at 11:23:50PM +0000, David-Sarah Hopwood wrote: > Nicolas Williams wrote: > > [...] > > I agree completely with both your characterization of the situation, > and statements of opinion. Thanks. You and I do disagree, however, as to whether it was premature to start an IETF LC. I believe there's only one matter to resolve, and that it is appropriate to resolve it during an IETF LC. Note to fail-safe proponents: IMO the RI proposal is the default outcome of this LC. A single, unified proposal has to be put on the table if we're to find consensus for fail-safe, and, too, I think support from major implementors is needed. If such a proposal and support fail to materialize then I'd expect the conclusion to be that the RI proposal is it. I'm a proponent of fail-safe, but not neither a TLS implementor nor sufficiently energetic to make it happen. One (or more) of you will have to organize an off-list agreement in order to make this happen. Attempting to design and finalize an alternative on this LC is a bad idea. Nico -- From mrex@sap.com Mon Nov 30 16:22:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5B928C15C for ; Mon, 30 Nov 2009 16:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 XRQanvXLP7RZ for ; Mon, 30 Nov 2009 16:22:07 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 3FFAD28C14F for ; Mon, 30 Nov 2009 16:22:07 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB10LveY001347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 01:21:57 +0100 (MET) From: Martin Rex Message-Id: <200912010021.nB10Lu1H000702@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Tue, 1 Dec 2009 01:21:55 +0100 (MET) In-Reply-To: <20091130210555.D8EA76C3EE1@kilo.networkresonance.com> from "Eric Rescorla" at Nov 30, 9 01:05:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 00:22:08 -0000 Eric Rescorla wrote: > > Nicolas Williams wrote: > > > > - The RI proposal has a fail-unsafe requirement that peers check the > > contents of the extensions sent. > > > > NOTE: A fix for this wouldn't require an extension-less signalling > > solution. > > in particular, in order for the failure you're concerned about to occur, > this failure requires *both* sides to be incorrectly implemented. As I previously described, this assumption is incorrect. It is sufficient when one side is incorrectly implemented. Scenario: MitM proxies the initial handshake of a client into the renegotiation of a server. Client will send empty TLS extension RI. If the server implementor has implemented the signaling in the fashion "receiving empty RI" -> "sending empty RI", then the handshake will succeed. Server goofed it, and the client has no chance to detect it and no chance to prevent it. -Martin From mrex@sap.com Mon Nov 30 18:05:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54733A6AD2 for ; Mon, 30 Nov 2009 18:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 JAQoAHDRdRgN for ; Mon, 30 Nov 2009 18:05:40 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 9242C3A6ACE for ; Mon, 30 Nov 2009 18:05:40 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB125TUZ018869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 03:05:29 +0100 (MET) From: Martin Rex Message-Id: <200912010205.nB125SkT006982@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Tue, 1 Dec 2009 03:05:28 +0100 (MET) In-Reply-To: <4B1416D0.60500@extendedsubset.com> from "Marsh Ray" at Nov 30, 9 01:02:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 02:05:41 -0000 Marsh Ray wrote: > > No compromise on actual protocol security of course, but no time to > delay for aesthetics either. > > > [1] The simplest such change would be have the peers send zeros in the > > extensions but modify the hellos to insert the CB data prior to > > hashing the hellos as part of the verify_data computation. > > Changing inputs to the hash function theoretically introduces new > possibilities for attack (verify_data which looks like a valid handshake > message prefix for example). > > I fear that any change to the way the hashing inputs are done will > trigger a formal crypto review in some important deployments. That seems a little far fetched, given that MitM attackers have no restrictions of any kind to feed whatever they like into the handshake message hash. Quoting from rfc5246 7.4.1.4 Hello Extensions: Often the fact that the extension fields are included in the inputs to the Finished message hashes will be sufficient, but extreme care is needed when the extension changes the meaning of messages sent in the handshake phase. Designers and implementors should be aware of the fact that until the handshake has been authenticated, active attackers can modify messages and insert, remove, or replace extensions. The problem that David-Sarah Hopwood noticed in my initial approach was that my change only inserted data in the renegotiation, it did _not_ insert different data on the initial handshake. So there was a theoretical attack that the attacker might be able to insert what one side added into the message stream for the other--which had not added for an initial handshake, provided there was an accidental collision with a de-facto no-op handshake message. The attack is fairly theoretical, because the verify_data is not predictable (for TLS sessions where the attacker controls only one side) and the protocol itself does not define any no-op handshake messages (but implementations could have bugs to this effect). The obvious fix is to add reliably distinct data in both initial and renegotiation handshake. The handshake message protection comes from the fact that an attacker may only insert data into the message streams (and get them added to the handshake message hashes this way), but not remove any of the data previously added by either side. -Martin From ekr@networkresonance.com Mon Nov 30 19:10:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268F13A67E4 for ; Mon, 30 Nov 2009 19:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M1YMar7eQTC for ; Mon, 30 Nov 2009 19:10:46 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 1CC273A67E6 for ; Mon, 30 Nov 2009 19:10:46 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C11756C4000; Mon, 30 Nov 2009 19:11:44 -0800 (PST) Date: Mon, 30 Nov 2009 19:11:43 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200912010021.nB10Lu1H000702@fs4113.wdf.sap.corp> References: <20091130210555.D8EA76C3EE1@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091201031144.C11756C4000@kilo.networkresonance.com> Cc: Nicolas.Williams@sun.com, tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 03:10:47 -0000 At Tue, 1 Dec 2009 01:21:55 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > Nicolas Williams wrote: > > > > > > - The RI proposal has a fail-unsafe requirement that peers check the > > > contents of the extensions sent. > > > > > > NOTE: A fix for this wouldn't require an extension-less signalling > > > solution. > > > > in particular, in order for the failure you're concerned about to occur, > > this failure requires *both* sides to be incorrectly implemented. > > > As I previously described, this assumption is incorrect. > It is sufficient when one side is incorrectly implemented. > > Scenario: MitM proxies the initial handshake of a client into > the renegotiation of a server. Client will send empty TLS extension RI. > If the server implementor has implemented the signaling in the fashion > "receiving empty RI" -> "sending empty RI", then the handshake will > succeed. Server goofed it, and the client has no chance to detect > it and no chance to prevent it. As far as I can tell, exactly the same thing can happen with an implicit proposals, if, for instance, the server always inserts empty verify_data. Sure, that could be caught in testing, but so could the error you propose with RI. As a distinguishing factor, this seems pretty marginal at best. -Ekr From mike-list@pobox.com Mon Nov 30 19:42:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED103A67C2 for ; Mon, 30 Nov 2009 19:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 G09O7fD0HmRT for ; Mon, 30 Nov 2009 19:42:40 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 229EC28C19B for ; Mon, 30 Nov 2009 19:42:38 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DEFC88428C for ; Mon, 30 Nov 2009 22:42:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Ev2cMXA3cMty RADoQ/pE8Ik1xL4=; b=H/Fgr0zgL5irWD69293KKbwNKBEHK9rJDUAUKVUksuUf 2ZbA9Xtre61pOG7zvikeDjz07rkWFd5Th5ELHXPhAFzVY3T9EQ843F5zk/H4I0G8 7x4nOjc7zfGgyS9enMwZoH9ZF0naWASXp3drwjEDCzyiBlhBegzMv94sA5a31R0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=v4bf+A Wlc/gvfs8IeH51WxWAjNdZQsF7a6fIoE5wgBMLynu8QkavDmYOcyhF62by462XNl m6CpC4DbJ2XDnS4bQEpimcBUKrSqTwUZ4PwCKhucYSwmXAfwgCIfNl8IW27zaSku TeNp1lquFAmZp+rJ4XPTLsNK4V2X93d1l1tQE= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DA7088428B for ; Mon, 30 Nov 2009 22:42:30 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 655C68428A for ; Mon, 30 Nov 2009 22:42:30 -0500 (EST) Message-ID: <4B1490F9.2050106@pobox.com> Date: Mon, 30 Nov 2009 19:43:53 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <20091130170745.GH773@Sun.COM> <4B145406.7050905@jacaranda.org> <20091130233045.GA773@Sun.COM> In-Reply-To: <20091130233045.GA773@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 8D9D9B72-DE2B-11DE-8D3A-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 03:42:41 -0000 Nicolas Williams wrote: > On Mon, Nov 30, 2009 at 11:23:50PM +0000, David-Sarah Hopwood wrote: >> Nicolas Williams wrote: >>> [...] >> I agree completely with both your characterization of the situation, >> and statements of opinion. > > Thanks. You and I do disagree, however, as to whether it was premature > to start an IETF LC. I believe there's only one matter to resolve, and > that it is appropriate to resolve it during an IETF LC. There is something that you may have overlooked. With the RI proposal, SSLv3 and TLS clients that don't currently support extensions will only be able to make initial connections to servers using the special cipher suite. If they ever need to renegotiate, they need to add full support for extensions since RI requires the verify_data be sent and received in renegotiation handshakes. You know my position is that this is entirely unnecessary baggage that should not be forced on implementers that don't have extensions in their code already. Add to that the fail-safe/unsafe issue, and it seems to be a no-brainer to choose the alternative (which Martin should be releasing tomorrow). Mike > Note to fail-safe proponents: IMO the RI proposal is the default outcome > of this LC. A single, unified proposal has to be put on the table if > we're to find consensus for fail-safe, and, too, I think support from > major implementors is needed. If such a proposal and support fail to > materialize then I'd expect the conclusion to be that the RI proposal is > it. I'm a proponent of fail-safe, but not neither a TLS implementor nor > sufficiently energetic to make it happen. One (or more) of you will > have to organize an off-list agreement in order to make this happen. > Attempting to design and finalize an alternative on this LC is a bad > idea. > > Nico From rms@gnu.org Mon Nov 30 20:09:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974063A68BA for ; Mon, 30 Nov 2009 20:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 AxRik8zQQs0j for ; Mon, 30 Nov 2009 20:09:39 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id DF9C13A6A0E for ; Mon, 30 Nov 2009 20:09:38 -0800 (PST) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NFK3N-0008OA-T7; Mon, 30 Nov 2009 23:09:29 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Todd Glassey In-reply-to: <4AB3A5F6.1030202@earthlink.net> (message from Todd Glassey on Fri, 18 Sep 2009 08:23:34 -0700) References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> Message-Id: Date: Mon, 30 Nov 2009 23:09:29 -0500 Cc: tls@ietf.org, ietf-honest@lists.iadl.org Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (Keying X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rms@gnu.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 04:09:39 -0000 Dan - the IPR notice is a statement of the ownership of the IP It is a bad practice to use the term "intellectual property" to talk about anything, because that term is harmfully broad. No matter which law is the real topic, confusing it with other laws is not good. These issues concern patents and only patents. (Copyrights and trademarks could not raise issues like these.) So we can avoid spreading confusion by speaking of "notices about patents" and "ownership of the patents", and avoiding the term "IP". It's easy to do, so how about it? From mrex@sap.com Mon Nov 30 20:54:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4392928C133 for ; Mon, 30 Nov 2009 20:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 K8xGxaDRdNU2 for ; Mon, 30 Nov 2009 20:54:51 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 4372C28C14C for ; Mon, 30 Nov 2009 20:54:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB14sgMH028134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 05:54:42 +0100 (MET) From: Martin Rex Message-Id: <200912010454.nB14sfh1017337@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Tue, 1 Dec 2009 05:54:41 +0100 (MET) In-Reply-To: <20091201031144.C11756C4000@kilo.networkresonance.com> from "Eric Rescorla" at Nov 30, 9 07:11:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: Nicolas.Williams@sun.com, tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 04:54:52 -0000 Eric Rescorla wrote: > > At Tue, 1 Dec 2009 01:21:55 +0100 (MET), > Martin Rex wrote: > > > > Eric Rescorla wrote: > > > > > > Nicolas Williams wrote: > > > > > > > > - The RI proposal has a fail-unsafe requirement that peers check the > > > > contents of the extensions sent. > > > > > > > > NOTE: A fix for this wouldn't require an extension-less signalling > > > > solution. > > > > > > in particular, in order for the failure you're concerned about to occur, > > > this failure requires *both* sides to be incorrectly implemented. > > > > > > As I previously described, this assumption is incorrect. > > It is sufficient when one side is incorrectly implemented. > > > > Scenario: MitM proxies the initial handshake of a client into > > the renegotiation of a server. Client will send empty TLS extension RI. > > If the server implementor has implemented the signaling in the fashion > > "receiving empty RI" -> "sending empty RI", then the handshake will > > succeed. Server goofed it, and the client has no chance to detect > > it and no chance to prevent it. > > As far as I can tell, exactly the same thing can happen with an > implicit proposals, if, for instance, the server always inserts > empty verify_data. Sure, that could be caught in testing, but > so could the error you propose with RI. There is a huge difference. With the implementations where there verify_data is added directly into the handshake messsage hash, the error will be pretty obvious in each and every regular interop test due to a complete lack of interoperability. With TLS extension RI, you will notice the problem only when you perform real penetration tests or source code review. It would be a significant additional amount of work to implement it incorrectly and still interoperate, so it's fairly unlikely someone will do this rather than the much easier correct and interoperable solution. -Martin From gwz@net-zen.net Mon Nov 30 20:52:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D749E28C1AE for ; Mon, 30 Nov 2009 20:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 nWwT-z5Bb9Y0 for ; Mon, 30 Nov 2009 20:52:50 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 2B46428C14C for ; Mon, 30 Nov 2009 20:52:50 -0800 (PST) Received: (qmail 17627 invoked from network); 1 Dec 2009 04:52:40 -0000 Received: from unknown (24.22.129.187) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 01 Dec 2009 04:52:40 -0000 From: "Glen Zorn" To: References: <20091130153734.D44C63A6AA9@core3.amsl.com> <7E1DF37F1F42AB4E877E492C308E6AC4028472C6@XCH57YKF.rim.net> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC4028472C6@XCH57YKF.rim.net> Date: Mon, 30 Nov 2009 20:51:28 -0800 Organization: Network Zen Message-ID: <002701ca7242$1556d2a0$400477e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpx01KW4vupGUWDS4aFcmDgcLATCgADLHcgAAq3iqA= Content-Language: en-us X-Mailman-Approved-At: Mon, 30 Nov 2009 21:02:22 -0800 Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 04:52:50 -0000 Paragraph 3 of section 4 says: Because this cipher suite is equivalent to an empty "renegotiation_info" extension, only renegotiation_info" may be used rehandshakes. Leaving aside the incorrect punctuation, this doesn't make any sense to me. In section 5, suggest replacing all occurrences of the word "draft" with the word "specification". In section 6.2, s/NOT allow clients who do not offer the "renegotiation_info" extension/NOT allow clients which do not offer the "renegotiation_info" extension/.